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DESCRIPTION  OF  THE  SOFTWARE 


A.  Program  Name:  Acquisition  of  Supportable  Systems  Evaluation  Technology 
(ASSET). 

B.  Version  Name:  Since  there  is  only  one  version  of  this  program,  the 
version  name  is  identical  to  the  program  name  above. 

C.  Software  Technical  Description:  The  models  included  in  ASSET  are  hosted 
on  the  Control  Data  Corporation  CYBER  System,  Wright-Patterson  AFB,  Ohio.  The 
primary  program  language  for  the  models  is  FORTRAN.  Unique  features  of  the 
operating  system  must  be  taken  into  account  when  implementing  this  software  on 
a  different  system.  Volume  II  contains  detailed  operating  instructions  for 
the  models. 


INSTRUCTIONS  FOR  REQUESTING  COPIES 


For  more  information  regarding  this  program  contact  the  Acquisition 
Logistics  Branch  of  the  Logistics  and  Human  Factors  Division,  Air  Force  Human 
Resources  Laboratory  (AFHRL/LRA).  Commercial  Phone:  (513)  255-3871; 
AUTOVON:  785-3871. 

RELEASE  INSTRUCTIONS 

Software  normally  can  be  released,  free  of  charge,  to  Federal,  state  and 
local  government  agencies  upon  approval  by  higher  headquarters.  Requesting 
agencies  should  complete  the  Air  Force  Standard  Statement  of  Terms  and 
Conditions  included  in  this  document  and  forward  the  completed  statement  to 
AFHRL/LRA,  Wright-Patterson  AFB,  Ohio  45433-6503.  The  cover  letter  for  the 
request  should  be  prepared  on  agency  letterhead  and  include  the  name,  address, 
and  phone  number  of  a  contact  point.  If  software  is  to  be  transmitted  in 
machine  readable  form,  the  requesting  agency  should  be  prepared  to  supply  the 
blank  magnetic  tape  reels. 
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STATEMENT  OF  TERMS  AND  CONDITIONS 


RELEASE  OF  AIR  FORCE-OWNED  OR  DEVELOPED  CQftfUTER  SOFTWARE 


DATE: 


1.  In  accordance  with  the  provisions  of  AFR  300-6,  release  of  the  following 
U.S.  Air  Force  software  package  {computer  programs,  systems  descriptions, 
and/or  documentation)  is  requested: 


2.  The  requested  software  package  will  be  used  for  the  following  purposes: 


Such  use  is  projected  to  accrue  benefit  to  the  Government  as  follows: 


3.  I/we  will  be  responsible  for  assuring  that  the  software  that  we  received 
will  not  be  used  for  any  purpose  other  than  shown  in  paragraph  2  above;  also, 
it  will  not  be  released  to  anyone  without  the  prior  approval  of  the  Air  Force. 
Further,  the  release  of  the  requested  software  package  will  not  result  in  com¬ 
petition  with  other  software  packages  offered  by  commercial  firms. 


4.  I/we  guarantee  that  the  provided  software  package,  and/or  any  modified 
version  thereof,  will  not  be  published  for  profit  or  in  any  manner  offered  for 
sale  to  the  government;  it  will  not  be  sold  or  given  to  any  other  activity  or 
firm,  without  the  prior  written  approval  of  the  Air  Force.  If  this  software 
is  modified  or  enhanced  using  government  funds,  the  Government  owns  the 
results,  whether  the  software  is  the  basis  of,  or  incidental  to  a  contract. 
The  Government  shall  not  pay  a  second  time  for  this  software  or  the 
enhanced/modified  version  thereof.  The  package  may  be  used  in  contract  with 
tl  Government  but  no  charge  may  be  made  for  its  use. 


5.  The  U.S.  Air  Force  is  neither  liable  nor  responsible  for  maintenance, 
updating  or  correction  of  any  errors  in  the  software  package  provided. 


6.  I/we  understand  that  no  material  subject  to  national  defense  security 
classification  or  proprietary  right  was  intended  to  be  released  to  us.  I/we 
will  report  promptly  the  discovery  of  any  material  with  such  restrictions  to 
the  Air  Force  approving  authority.  I/we  will  follow  all  instructions  concern¬ 
ing  the  use  or  return  of  such  material  in  accordance  with  regulations  applying 
to  classified  material,  and  will  make  no  further  study,  use  or  copy  such  mate¬ 
rial  subject  to  security  or  proprietary  rights  marking. 

7.  I/we  understand  that  the  software  package  received  is  intended  for  domes¬ 
tic  use  only.  It  will  not  be  made  available  to  foreign  governments  nor  used 
in  any  contract  with  a  foreign  government. 


Signature  of  Requestor 
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SUMMARY 


This  users  guide  provides  information  about  the  procedures  and  analytical 
tools  contained  in  the  Acquisition  of  Supportable  Systems  Evaluation 
Technology  (ASSET)  methodology.  It  consists  of  six  computer  models  and  eight 
procedures.  The  models  are  (a)  Reliability  and  Maintainability  (RM),  (b) 
Readability  and  Maintainability  Cost  Model  (RMCM),  (c)  Training/Aiding  Matrix 
(TAM),  (d)  Page-Estimating  Equations  (PAGES),  (e)  Training  Requirements 
Analysis  Model  (TRAMOD),  and  (f)  Personnel  Availability  Model  (PAM).  The 
procedures  are  (a)  Program  Definition  Analysis,  (b)  Consolidated  Data  Base 
Development,  (c)  Maintenance  Action  Network,  (d)  Integrated  Task  Analysis,  (e) 
Logistics  Resources  Assessment,  (f)  Comparability  Analysis,  (g)  Life  Cycle 
Cost  Assessment,  and  (h)  Design  Option  Decision  Tree.  This  users  guide 
provides  the  input  requirements,  detailed  output,  access  instructions,  and 
algorithms  of  four  of  the  computer  models  (RM,  RMCM,  TAM,  and  PAGES).  TRAMOD, 
and  PAM  documentation  is  referenced  in  the  users  guide  but  not  involved. 
General  information  regarding  the  procedures  is  also  provided. 
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PREFACE 


A  number  of  different  technologies  have  been  developed  under  the 
auspices  of  the  Air  Force  Human  Resources  Laboratory.  These 
technologies  are  applied  to  a  hardware  system  to  examine  various  criti¬ 
cal  support  elements  and  provide  quantitative  decision  making  informa¬ 
tion  towards  evaluation  of  design  alternatives  and  reducing  the  life 
cycle  cost  of  the  system.  These  technologies'  are  integrated  into  the 
Acquisition  of  Supportable  Systems  Evaluation  Technology  (ASSET). 


This  document  is  the  User's  Guide  for  the  ASSET  package.  The  pro¬ 
cedures,  models  and  consolidated  data  base  comprising  the  ASSET  method¬ 
ology  are  described  to  provide  an  understanding  of  their  capabilities 
and  use  in  applications. 
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CHAPTER  1.  INTRODUCTION 


1.1  GENERAL 

This  document  is  the  User's  Guide  for  the  application  of  the 
ASSET,  Acquisition  of  Supportable  Systems  Evaluation  Technology,  to  a 
military  weapon  system  acquisition.  ASSET  is  a  systematic,  procedural- 
ized  methodology  that  is  used  to: 

a.  Provide  assessments  of  cost,  human  resources,  and  logistics 
resources  required  for  support  and  operation  of  weapons  sys¬ 
tems,  evaluated  during  early  conceptual  phases  through  produc¬ 
tion  and  deployment. 

b.  Coordinate  the  development  of  training  programs  and  technical 
manuals  to  ensure  complete  and  cost-effective  maintenance  per¬ 
formance  instructions. 

c.  Ensure  that  supportabi 1 ity  considerations  and  human  resource 
impacts  are  explicitly  considered  in  the  design  of  the  weapon 
system  and  are  traceable. 

The  application  of  ASSET  to  a  developing  weapon  system  permits  and 
encourages  the  early  integration  of  design,  logistics  support,  and 
operational  concepts  so  that  their  mutual  influence  may  result  in  a 
cost-effective,  supportable  system.  This  follows  policy  guidelines  in¬ 
corporated  in  Department  of  Defense  Directives  5000.1  and  5000.39  and 
AFRs  800-2  and  800-8  which  emphasize  the  importance  of  integrated 
logistics  support  planning  throughout  the  acquisition  program  and 
especially  in  the  early,  conceptual  phase. 

The  ASSET  methodology  is  also  in  accordance  and  agreement  with  the 
Logistics  Support  Analysis  (LSA)  as  identified  in  MIL-STD-1388.  In 
this,  LSA  is  defined  as  a  composite  of  systematic  actions  taken  to 
identify,  define,  analyze,  quantify,  and  process  logistics  support  re¬ 
quirements.  This  includes  those  activities  that  are  conducted  to  evalu¬ 
ate  and  compare  system  design  and  operational  characteristics  to  make 
objective  logistics  support  decisions.  The  goal  of  LSA  is  to  achieve 
balance  between  system  readiness,  operational  capability,  and  logistics 
requirements  at  a  minimum  life  cycle  cost.  The  ASSET  assists  in  the 
achievement  of  this  goal. 

1.2  ASSET  DESCRIPTION 

The  significant  factors  that  contribute  to  successful  acquisition 
or  development  of  cost-effective  weapon  systems  are  the  identification 
of  support  requirements  and  the  identif icaiton  of  cost-reducing  alter¬ 
natives  to  existing  or  baseline  structures.  The  ASSET  methodology  con¬ 
tributes  to  both  factors.  The  design  of  the  methodology  is  such  that 
high  resource  consumers  such  as  manpower,  logistics  support  elements, 
and  other  life  cycle  cost  drivers  are  readily  identified  upon  appli¬ 
cation  of  the  procedures  and  models  to  a  baseline  or  alternative  sys¬ 
tem.  Since  high  consumption  areas  offer  the  greatest  potential  return 
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for  modification  efforts,  their  identification  directs  design/support 
engineers  to  specific  subjects  for  trade-off  studies.  The  ASSET 
methodology  presents  detailed  comparisons  of  configuration  alternatives 
in  terms  of  cost  and  resource  requirements. 

The  basic  elements  of  ASSET  are  eight  analysis  procedures,  eight 
analytical  computer  models,  and  a  single  consolidated  data  base.  These 
are  depicted  in  figure  1-1.  The  application  of  ASSET  revolves  around 
the  analysis  procedures.  The  analytical  computer  models  are  used  as 
tools  to  support  the  procedures.  The  consolidated  data  base  serves  as 
the  single  depository  of  data  to  support  the  ASSET  application.  The 
procedures  and  models  in  ASSET  may  be  applied  as  an  entirety  to  a  com¬ 
plete  weapon  system  or  selected  portions  of  the  methodology  may  be  used 
for  analysis  of  specific  components  of  a  system.  The  depth  and  breadth 
of  application  can  be  tailored  by  the  user,  depending  upon  the  scope 
and  constraints  of  the  analysis  effort. 

The  procedures  and  models  provided  in  the  ASSET  methodology  com¬ 
plement  the  LSA  procedures  defined  in  MIL-STD-1388  by  identifying  sup¬ 
port  resources  and  costs  as  a  result  of  the  ASSET  analysis  techniques. 
ASSET  also  provides  procedures  for  accomplishing  tasks  which  are  re¬ 
quired  or  specified  by  the  LSA  process  but  not  detailed  with  respect  to 
technique,  such  as  evaluation  of  alternatives  and  defining  resource  re¬ 
quirements.  Finally,  ASSET  enhances  the  LSA  process  by  providing  model¬ 
ing  capabilities  necessary  for  a  thorough  LSA  including  life  cycle  or 
system  ownership  costing. 


LSA  Records,  LSAR,  are  the  documented  data  of  the  system  design 
and  support  requirements,  which  result  from  integrating  operational  re¬ 
quirements  and  logistics  support  considerations.  The  Department  of  De¬ 
fense  requires  that  documented  LSA  be  performed  on  all  hardware  systems 
acquired.  The  Logistics  Support  Analysis  process  is  continuous  from 
the  conceptual  stage  through  production  and  deployment.  However,  LSAR, 
the  documented  results  of  the  LSA,  are  not  normally  prepared  prior  to 
full-scale  development.  LSAR  data  sheets  are  generally  prepared  by  a 
contractor  to  meet  Contractor  Data  Requirements  List  (CDRL)  specifica¬ 
tions.  In  fact,  as  stated  in  DARCOM-P  750-16,  LSAR  data  sheets  are  not 
initiated  for  an  item  until  its  configuration  is  stabilized;  that  is, 
not  until  all  design  alternatives  have  been  weighed.  ASSET  thus  accom¬ 
panies  and  benefits  the  LSA  by  providing  a  means,  through  its  consoli¬ 
dated  data  base  (CDB),  to  document  early  design  configurations  and 
trade  studies.  The  data  in  the  CDB  can  then  be  transitioned  to  the 
LSAR  at  a  later  time. 

The  ASSET  methodology  consists  of  definition,  collection,  and  pro¬ 
cessing  of  appropriate  data  to  meet  the  functions  stated  above.  In  the 
early  conceptual  phase,  data  may  be  derived  from  historical  files  of 
existing  systems  to  form  a  baseline  for  comparison  of  the  new  system. 
As  the  design  of  a  new  system  is  formulated  and  feasible  alternatives 
are  identified,  data  are  developed  for  each  alternative  to  assess  the 
associated  costs  and  resources  for  comparison  to  the  baseline  and  to 
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Figure  1-1.  Elements  of  ASSET  Methodology 


each  other.  This  iterative  process  leads  to  identification  of  the 
least  total  cost  alternative  that  meets  operational  performance  and 
logistics  requirements  and  identifies  the  resources  necessary  for  oper¬ 
ation  and  support  of  the  resulting  weapon  system. 
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1.3  GUIDE  ORGANIZATION 

The  ASSET  User's  Guide  is  organized  into  two  major  books.  8ook  I 
contains  information  relating  to  the  general  ASSET  methodology  and  to 
the  application  of  the  procedures  and  associated  models  to  a  weapon 
system  acquisition.  Book  II  contains  information  relating  the  actual 
computer  operation  of  the  more  specific  analytical  models. 

Book  I  consists  of  five  chapters.  The  first  chapter  presents  an 
introduction  to  the  ASSET  methodology  and  to  the  User's  Guide.  The 
second  and  third  chapters  contain  overviews  of  the  ASSET  procedures  and 
analytical  computer  models,  respectively.  The  fourth  chapter  presents 
an  integration  of  the  ASSET  with  a  "typical"  conceptual  phase  of  a  wea¬ 
pon  system  acquisition  program.  The  fifth  and  final  chapter  outlines 
each  analysis  procedure. 

Book  II  consists  of  eight  independent  chapters,  each  dealing  with 
a  separate  computer  model.  Each  chapter  is  self-suff icient  in  contain¬ 
ing  model  description,  input  requirements,  operating  instruction  and 
output  results  description  for  the  specific  model. 

There  is  also  a  separate  supplement  user's  guide  which  contains 
the  source  listings  for  six  of  the  models  associated  with  the  ASSET.  A 
model  logic  flow  diagram  for  each  model  is  also  included  along  with 
sample  input  data  sets  and  output  reports.  Note  that  ASSET  also  incor¬ 
porates  two  additional  existing  models,  which  are  well  documented,  for 
a  total  of  eight  models. 
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CHAPTER  2.  ASSET  PROCEDURES  OVERVIEW 


This  section  of  the  ASSET  Application  User's  Guide  contains  a  gen¬ 
eralized  overview  of  the  individual  procedures  incorporated  in  the 
ASSET.  The  integrating  ties  and  relationships  between  the  procedures 
which  unify  the  methodology  are  also  presented. 

2.1  GENERAL 

ASSET  is  applied  through  a  series  of  procedures  which  are  used  to 
define  program  requirements,  generate  and  analyze  data,  and  perform 
trade-offs  of  design  and  support  alternatives.  The  procedures  which 
comprise  the  integral  part  of  ASSET  are: 

a.  Program  Definition  Analysis  Procedure. 

b.  Consolidated  Data  Base  Procedure. 

c.  Integrated  Task  Analysis  Procedure. 

d.  Maintenance  Action  Network  Procedure. 

e.  Logistic  Resources  Assessment  Procedure. 

f.  Comparability  Analysis  Procedure. 

g.  Life  Cycle  Cost  Assessment  Procedure. 

h.  Design  Option  Decision  Tree  Procedure. 

These  eight  procedures  are  applied  consecutively  and/or  in  paral¬ 
lel  in  an  ASSET  application,  depending  on  particular  program  require¬ 
ments  and  constraints. 

A  typical,  prototype  ASSET  application  is  shown  in  figure  1-2. 
ASSET  concentrates  analysis  in  three  of  the  procedures;  the  Integrated 
Task  Analysis  Procedure,  Logistic  Resources  Assessment  Procedure  and 
Life  Cycle  Cost  Assessment  Procedure.  Through  these,  the  supportabil- 
ity  of  a  weapon  system  is  analyzed  for  evaluation  in  terms  of  logistic 
resources  (including  human  resources)  and  life  cycle  cost.  The  Mainte¬ 
nance  Action  Network  and  Comparability  Analysis  Procedure  provide  link¬ 
age  to  the  technology  and  a  means  for  a  comparison  activity.  The  Pro¬ 
gram  Definition  Analysis  Procedure  sets  the  environment  for  the  ASSET 
application  and  the  Consolidated  Data  Base  (CDB)  Procedure  provides  a 
CDB  for  all  information  collected  and  generated  during  the  application. 
The  Design  Option  Decision  Tree  Procedure  presents  a  method  to  inject 
supportabi lity  factors  and  evaluation  into  the  existing  DODT 
methodology. 

The  ASSET  procedures  are  supported  by  several  analytical  computer 
models  developed  and  modified  for  use  in  ASSET.  These  models  are  util¬ 
ized  as  tools  in  the  performance  of  the  procedures.  Figure  1-3 
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Figure  1-2.  Prototype  ASSET  Application 


presents  a  correlation  and  interface  between  the  ASSET  procedures  and 
computer  models,  showing  the  models  which  may  support  each  procedure. 

The  following  paragraphs  contain  a  further  description  of  each 
procedure  and  identify  the  computer  models  which  may  be  utilized  in 
support  of  the  procedure. 

2.2  PROGRAM  DEFINITION  ANALYSIS  PROCEDURE 

The  Program  Definition  Analysis  (PDA)  is  the  initial  effort  that 
must  be  conducted  to  put  the  weapon  system  (and/or  systems  of  special 
interest)  into  context  for  ASSET  application.  The  specific  goals  of 
the  ASSET  application  are  well-defined  through  this  analysis  effort  so 
that  the  resources  and  activity  may  be  limited  to  achieving  those 
goals. 

None  of  the  associated  ASSET  computer  models  are  directly  used  in 
the  determination  of  scope  and  level  of  detail  to  be  accomplished  dur¬ 
ing  the  PDA  procedure.  Rather,  a  general  knowledge  of  all  the  models, 
such  as  that  presented  in  Book  I,  Chapter  3  of  this  User’s  Guide,  will 
assist  in  the  selection  of  appropriate  models  to  support  and  achieve 
the  goals  of  a  particular  application  program. 
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Initially,  a  review  of  external  data  sources  is  made  to  establish 
the  program  requirements , including  a  key  event  and  operational  readi¬ 
ness  schedule,  and  a  detailed  phased  schedule.  Both  contain  the  produc¬ 
tion  and  operational  planning  information  necessary  to  perform  resource 
and  cost  assessment.  The  prime  data  source  from  which  these  schedules 
may  be  developed  is  the  weapon  system  Program  Management  Plan,  which 
contains  the  planning,  responsibilities,  management  techniques  and  con¬ 
trols  required  during  the  weapon  system  acquisition  process. 

The  support  plans,  a  series  of  basic  statements  describing  the  ILS 
elements  and  reflecting  the  latest  ILS  decisions,  are  also  identified. 
This  information  is  used  as  a  guide  in  the  development  of  the  mainte¬ 
nance  action  networks  because  these  networks  must  reflect  the  planned 
methods  of  maintenance  support  as  well  as  the  appropriate  maintenance 
actions.  In  some  cases,  it  may  be  necessary  to  provide  a  support  plan 
for  each  subsystem.  For  example,  separate  support  plans  may  be  desir¬ 
able  for  engines  and  avionics. 

Data  files  are  established  to  include  the  program  requirements  and 
support  plans  as  well  as  information  on  maintenance  activities,  deploy¬ 
ment  and  system  use,  the  operations  schedule,  and  a  preliminary  listing 
of  alternatives.  Simultaneously,  the  system  design  data  files  are 
established  with  equipment  configuration  data,  and  the  preliminary  in¬ 
formation  required  to  analyze  alternatives  and  to  prepare  design  option 
decision  trees  (DODTs),  when  required,  is  obtained. 

In  summary,  the  PDA  procedure  identifies  the  applicable  weapon 
system  design  and  support  requirements.  A  general  methodology  is  fol¬ 
lowed  to  identify  applicable  ASSET  procedures  and  models.  Included  is 
the  data  research  effort  required  to  identify  the  characteristic  data 
elements  which  define  the  weapon  system  program.  As  the  first  step  in 
the  ASSET  package,  it  contains  an  extremely  important  process  for  init¬ 
ializing  the  application  of  ASSET. 

2.3  CONSOLIDATED  DATA  BASE  PROCEDURE 

ASSET  is  supported  by  a  Consolidated  Data  Base  (CDB)  which  is  pre¬ 
pared  for  the  weapon  system  under  consideration.  The  data  base  con¬ 
tains,  at  a  single  location,  all  information  required  to  analyze  the 
human  resource  and  support  impacts  during  the  weapon  system  acquisition 
process.  The  CDB  procedure  sets  forth  a  definition  of  the  CDB  and  pre¬ 
sents  requirements  for  its  administration  and  control.  The  CDB  proce¬ 
dure  does  not  usually  involve  the  use  of  the  computer  models.  However, 
data  required  by  these  models  will  be  contained  in  the  CDB. 

The  CDB  is  established  and  maintained  to  support  the  application 
of  ASSET  during  weapon  system  acquisition  and  may  be  transitioned  for 
use  in  operational  and  support  planning  after  deployment.  The  CDB  con¬ 
tains  data  gathered  and  generated  by  all  the  ASSET  procedures  as  shown 
in  figure  1-4.  This  includes  the  files  and  data  elements  necessary  for 
the  determination  of  the  human  resource  considerations  related  to 
specific  designs  and  alternatives,  the  identification  of  designs  and 
policies  which  create  excessive  human  resource  demands,  and  the 
development  of  the  instructional  system  development  and  jot  guide 


development  products.  Tne  CDB  will  also  contain  system  ownership  cost 
data  which  will  use  the  human  resource  parameters  to  provide  system 
ownership  cost  and  total  life  cycle  cost  (LCC)  predictions. 

The  CUB  is  established  immediately  after  the  PDA  and  in  many  cases 
in  conjunction  with  the  PDA.  It  is  initially  developed  from  historical 
and  comparative  data.  It  can  then  be  updated  with  current  acquisition 
information  as  it  becomes  available.  The  CDB  in  the  ASSET  process  can 
contribute  to  the  logistic  support  analysis  (LSA)  in  an  acquisition 
program  and  provide  data  for  the  formal  LSA  Record.  If  the  particular 
weapon  system  acquisition  program  does  not  specify  LSA,  then  the  CDB 
can  stand  alone.  In  either  case,  the  CDB  provides  for  the  earlier 
documentation  of  more  specific  data,  derived  through  a  rational  pro¬ 
cess,  than  has  been  possible  with  existing  techniques. 

The  consolidated  data  base  is  required  to  support  the  application 
of  ASSET  on  a  weapon  system  acquisition  program.  The  CDB  may  also  be 
used  independently  for  operational  and  support  planning  after  deploy¬ 
ment  or  may  be  transitioned  into  a  LSA  Record  (LSAR)  data  base.  The 
consolidated  data  base  is  unique  to  each  weapon  system.  It  expands  in 
detail  with  time  as  the  weapon  system  acquisition  progresses.  The  CDB 
is  dynamic,  representing  alternatives  being  considered  as  well  as  base¬ 
line  approaches  and  is  designed  for  frequent  update  and  expansion.  The 
CDB  also  provides  a  means  for  historical  traceability  on  the  weapon 
system  development  process.  As  the  system  acquisition  proceeds  from 
design  through  development,  the  CDB  is  improved  in  accuracy  and  detail 
by  replacing  planning  and  historical  information  with  information  ac¬ 
quired  on  the  actual  system. 
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Figure  1-4.  Data  Flow  Into  the  CDB 
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2.4  INTEGRATED  TASK  ANALYSIS  PROCEDURE 


The  Integrated  Task  Analysis  Procedure  in  ASSET  outlines  a  system¬ 
atic  study  of  the  requirements  for  tasks  which  must  be  performed  to 
operate  and  maintain  a  weapon  system.  Results  of  the  task  analysis 
help  in  the  determination  of  training  objectives  and  of  the  behaviors 
and  tasks  a  technical  manual  must  support.  This  lays  the  foundation 
for  the  development  of  coordinated  training  and  technical  manual  pro¬ 
ducts.  Results  are  also  used  in  the  logistics  resource  assessment  and 
life  cycle  cost  assessment  procedures. 

The  integrated  task  analysis  procedure  identifies  tasks  and  re¬ 
quirements  presented  by  a  weapon  system.  This  analysis  may  benefit 
from  the  use  of  the  analytical  computer  models  associated  with  ASSET. 
Models  applicable  to  a  task  analysis  include: 

a.  Reliability  and  Maintainability  (RM)  Model. 

b.  Reliability,  Maintainability,  and  Cost  Model  (RMCM). 

c.  Training/Aiding  Matrix  (TAM)  Model. 

d.  Page  Estimating  (PAGES)  Model. 

e.  Training  Requirements  Analysis  Model  (TRAMOD). 

f.  Personnel  Availability  Model  (PAM). 

g.  Expected  Value  (EXPVAL)  Model. 

h.  Logistics  Composite  Model  (LCOM). 

The  selection  of  individual  models  for  use  is  an  option  of  the  user  or 
analyst.  Not  all  of  the  models  listed  above  may  be  applicable.  For 
example,  the  RM  model,  EXPVAL  model  and  LCOM  all  analyze  tasks  required 
to  support  a  weapon  system.  LCOM  is  a  simulation  model  while  the  RM 
and  EXPVAL  models  are  mean  or  average  value  models  and  require  differ¬ 
ing  inputs.  Thus,  an  analyst  may  elect  to  choose  only  one  of  these 
three  models  for  a  particular  application  program. 

There  are  essentially  two  levels  of  task  analysis:  (1)  the  initial 
task  identification,  and  (2)  the  subsequent  detailed  analysis  of  the 
identified  tasks.  The  initial  task  identification  results  are  recorded 
on  the  preliminary  task  identification  matrix  (PTIM).  The  subsequent 
detailed  analysis  is  documented  oh  task  analysis  work  sheets.  The  test 
equipment  and  tool  utilization  is  also  documented  on  the  work  sheets 
with  information  gained  from  the  detailed  task  analysis.  Later,  in¬ 
formation  is  extracted  and  recorded  on  an  annotated  task  identification 
matrix  (ATIM). 

The  first  steps  in  the  task  analysis  procedure  are  to  develop  a 
listing  of  the  hardware  components  of  the  weapon  system  to  the  level  at 
which  the  tasks  are  performed  and  to  identify  and  determine  the  initial 
allocation  of  maintenance  tasks  with  regard  to  the  equipment  breakdown. 


This  is  documented  on  the  PTIM.  The  maintenance  level  at  which  the 
task  will  be  performed  is  also  recorded  in  the  PTIM. 

The  next  step  in  the  procedure  is  the  specific  task  analysis  and 
the  completion  of  the  task  analysis  work  sheets.  These  work  sheets  are 
completed  to  describe  the  specific  tasks  in  detail.  The  purpose  of 
this  is  to  identify  and  verify  hardware  elements  and  maintenance  task 
steps,  describe  the  cue  and  accompanying  responses  for  each  step,  list 
the  tools  and  equipment  used,  and  to  evaluate  the  safety  hazards  and 
environmental  factors  related  to  each  task.  Throughout  the  actual  task 
analysis  and  the  completion  of  the  task  work  sheets,  the  analyst  must 

refer  to  the  user  description  and  the  set  of  ground  rules  describing 

the  task  scope  and  detail  to  be  documented  on  the  work  sheets. 

The  ATIM  is  a  later  revision  or  update  of  the  PTIM.  The  task 

identification  matrix  is  updated  to  document  the  hardware  components 
and  corresponding  tasks  identified  through  the  task  analysis  and  is  re¬ 
vised  to  specify  the  authorized  maintenance  level  at  which  each  task 

will  be  performed.  The  matrix  can  also  be  annotated  (thus  the  name 
ATIM)  with  information  documenting  the  results  of  the  training/ 
technical  manual  trade-offs.  Specifically,  each  task  can  be  identified 
as  to  whether  the  task  information  emphasis  should  be  placed  on  train¬ 
ing  (head),  manuals  (books),  or  jointly  on  both. 

A  final  item  of  the  ASSET  integrated  task  analysis  is  a  level  of 
detail  guide.  This  guide  is  established  to  assist  in  the  actual  tech¬ 
nical  manual  preparation.  It  contains  specific  guidelines  for  the 
material  to  be  included  in  the  manuals  and  the  depth  of  detail  regard¬ 
ing  task  procedures. 

2.5  MAINTENANCE  ACTION  NETWORK  PROCEDURE 

The  Maintenance  Action  Network  (MAN)  Procedure  is  used  for  depict¬ 
ing  the  maintenance  flow  of  a  system  and  for  defining  the  input  data 
used  in  the  application  of  ASSET  as  an  assessment  methodology.  The 
maintenance  action  network  describes  the  maintenance  system  in  terms  of 
resources  required  to  carry  out  the  maintenance  functions  necessary  to 
restore  a  system  to  operational  readiness.  This  network  uses  an  event 
tree  structure  which  defines  the  maintenance  events  that  result  when  a 
particular  subsystem  has  indicated  a  malfunction  and  requires  a  mainte¬ 
nance  action.  The  networks  can  be  used  by  themselves  to  understand  a 
weapon  system  and  its  support  options.  They  can  also  serve  as  an  input 
data  resource  for  the  ASSET  models. 

The  data  represented  on  the  maintenance  action  network  is  used  by 
the  following  models: 

a.  Reliability  and  Mainta inabi lity  Model. 

b.  Reliability,  Ma intainabi 1 ity  and  Cost  Model. 

d.  Expected  Value  Model. 

e.  Logistics  Composite  Model. 


The  level  of  detail  required  and  complexity  of  the  network  possible  for 
each  model  is  not  constant  and  can  thus  indicate  which  model  to  use  for 
a  particular  application. 

The  basic  maintenance  action  network  is  depicted  in  figure  1-5. 
This  subsystem  network  represents  the  unscheduled  maintenance  actions 
which  may  occur  and  could  be  used  to  represent  the  maintenance  actions 
for  equipment  such  as  a  radar  subsystem  of  the  avionics  system.  Pre¬ 
sently  in  the  methodology,  maintenance  actions  are  performed  either  at 
the  organizational  (flightline)  or  intermediate  (shop)  level.  Depot 
level  maintenance  is  related  through  the  not-repairable-this-station 
(NRTS)  branch.  This  network  structure  can  be  expanded  if  it  is  to 
cover  the  three  common  levels  of  maintenance  in  more  detail.  With 
minor  modification,  this  format  may  also  be  used  to  represent  scheduled 
maintenance. 

Each  node  in  the  network  representation  indicates  the  beginning 
and/or  end  of  a  specific  event  such  as  subsystem  failure,  set  up  sup¬ 
port  equipment,  or  troubleshoot.  With  the  exception  of  subsystem  fail¬ 
ure,  each  event  is  annotated  to  indicate  (1)  the  probability  that  the 
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Figure  1-5.  Basic  Maintenance  Action  Network 


event  will  occur,  (2)  the  time  to  complete  the  event,  (3)  the  mainte¬ 
nance  personnel  characteristics  (skills,  levels,  and  quantity)  to  sup¬ 
port  the  event,  and  (4)  the  support  equipment  (type  and  quantity)  re¬ 
quired  to  support  the  event.  Subsystem  failure  is  annotated  only  with 
the  probability  of  occurrence. 

The  maintenance  action  network  identifies  the  possible  maintenance 
outcomes  associated  with  a  subsystem  or  LRU  failure.  Associated  ASSET 
models  can  then  compute  the  total  demand  on  the  maintenance  system  by 
multiplying  the  support  resources  required  per  event  by  the  average 
frequency  of  event  occurrence  and  then  summing  across  all  maintenance 
events  associated  with  the  equipment  hierarchy.  Support  resources  are 
defined  in  terms  of  crew  size,  skill  categories,  skill  levels,  support 
equipment,  and  average  time  required  to  complete  the  tasks  associated 
with  the  event.  Event  frequency  is  defined  simply  as  the  per  flight 
hour  probability  of  that  event  occurring.  The  network  has  a  flexible 
structure  that  can  be  tailored  for  modeling  applications.  Additional 
model  inputs  from  the  modified  network  are  then  needed  to  handle  the 
additional  data. 

The  data  used  to  annotate  these  networks  in  the  early  acquisition 
phases  are  developed  from  an  analysis  of  historical  data  on  comparable 
equipment.  This  analysis  is  partially  judgmental  and  must  consider  the 
source  of  the  historical  data  and  the  intended  application  of  the  pro¬ 
posed  system.  Historical  data  is  gradually  replaced  with  actual  sub¬ 
system  data  as  the  hardware  is  designed,  built,  and  tested  and  usage 
data  is  collected.  The  networks,  therefore,  grow  from  an  estimated  to 
an  actual  model  of  the  maintenance  system. 

As  previously  mentioned,  the  data  represented  by  this  network  is 
used  by  the  RM  model  or  the  Logistics  Composite  Model  (LCOM)  to  deter¬ 
mine  the  manpower  and  support  equipment  resources  required  to  support 
the  maintenance  system.  The  complexity  of  the  network  reflects  the 
availability  of  data  and  interest  in  the  equipment.  LCOM  is  normally 
used  where  a  system  configuration  is  firmly  established,  where  the 
operational  scenario  is  known,  and  where  the  dynamics  of  the  personnel 
and  support  equipment  requirements  are  required  to  be  known. 

The  RM  model  uses  a  simplified  maintenance  action  network  consist¬ 
ing  of  up  to  seven  fliqhtline  and  three  shop  tasks.  Complex  networks 
can  then  be  formed  when  the  simplified  networks  are  extended,  as  they 
are  in  LCOM,  to  include  additional  tasks,  parallel  tasks,  and  tasks 
with  multiple  records.  In  a  simulation  using  LCOM,  the  maintenance 
action  networks  must  obey  a  set  of  rules  for  construction  of  a  network, 
but  need  not  adhere  to  any  specific  predefined  form. 

Maintenance  action  networks  form  the  underlying  structure  to  the 
tasks  analysis  procedure  and  the  models  included  in  ASSET.  The 
networks  can  aid  the  designer  in  graphically  displaying  the  events  and 
options  available  for  support  of  a  design  in  much  the  same  way  the  DODT 
describes  design  alternatives.  It  is  not,  however,  necessary  to 
explicitly  form  a  maintenance  action  network  for  every  application  of 
ASSET.  The  procedure,  however,  is  valuable  in  understanding  the  under¬ 
lying  structure  of  the  models,  can  focus  and  direct  the  data  collection 


efforts,  and  provides  a  graphical  tool  for  presenting  support  options. 
The  early  application  of  the  MAN  procedure  is  especially  useful  as  a 
first  step  to  later  use  of  the  LCOM  when  detailed  data  become  avail¬ 
able.  The  maintenance  action  network  approach  is  the  basis  for  LCOM 
analysis  and  its  early  application  in  ASSET  will  ensure  that  the  re¬ 
quired  data,  in  the  proper  form,  will  be  developed  during  the  acquisi¬ 
tion  process. 

2.6  LOGISTIC  RESOURCES  ASSESSMENT  PROCEDURE 

The  logistics  resources  assessment  procedure  is  used  to  identify, 
evaluate  and  challenge  the  logistic  resources  requirements  posed  by  a 
weapon  system.  Logistic  resources  include  such  items  as  manpower, 
skills,  tools,  support  equipment,  spares,  facilities,  training  and 
technical  manuals,  and  impact  the  total  support  of  the  weapon  system. 

The  logistic  resource  assessments  are  provided  by  the  application 
of  several  elements  which  are  part  of  the  ASSET  package.  Quantitative 
information  in  these  areas  results  from  the  application  of  the  method¬ 
ology.  The  value  of  logistic  resource  assessments  in  planning  for,  or 
in  designing  of,  a  weapon  system  has  been  established  by  the  many  main¬ 
tenance  models  in  use  and  the  LSA  process.  There  are  many  ways  to 
accomplish  this  and  many  techniques,  models,  and  data  systems  to  assist 
in  its  accomplishment.  To  provide  the  user  with  the  assessment  cap¬ 
ability,  ASSET  includes  several  options  within  the  models,  and  the  in¬ 
formation  contained  in  the  consolidated  data  base,  which  can  also  be 
used  to  support  the  formal  LSA  and  LSAR.  The  model  options  used  depend 
upon  the  specific  problem  being  investigated  and  the  analysis  techni- 
que(s)  selected  for  application. 

The  logistic  resources  assessment  procedure  may  utilize  any  or  all 
of  the  eight  models  associated  with  the  ASSET.  Some  models  emphasize 
particular  resources  and  thus  the  use  of  the  model  is  dependent  on 
whether  that  resource  is  of  interest  to  a  particular  application  pro¬ 
gram.  Examples  of  this  are  the  TAM  model  which  addresses  training  ver¬ 
sus  manual  content  for  tasks  and  the  PAGES  model  which  addresses  tech¬ 
nical  manual  page  estimates. 

Feasibility  demonstrations  performed  as  part  of  the  ASSET  evalua¬ 
tion  provided  logistic  resource  assessment  information  and  showed  how 
quantitative  results  can  achieved  and  used  to  influence  design.  The 
logistic  resource  data  provides  maintenance-specific  information  which 
is  particularly  useful  in  gaining  an  understanding  of  the  support  re¬ 
quirements  for  a  weapons  system. 

2.7  COMPARABILITY  ANALYSIS  PROCEDURE 

The  comparability  analysis  procedure  is  the  overall  process  in 
ASSET  used  to  develop  data  on  newly  proposed  or  designed  weapon  systems 
by  (1)  selecting  operational  equipment  similar  to  that  of  the  proposed 
weapon  system  and  (2)  adjusting  the  resource  data  associated  with  oper¬ 
ational  equipment  to  reflect  the  unique  characteristics  of  the  proposed 
equipment.  The  comparability  analysis  includes  the  development  of 
maintenance  demand  rates  for  the  proposed  equipment  which,  in  turn,  can 
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be  used  to  determine  resource  requirements  (such  as  manpower,  support 
equipment,  and  spares  for  the  weapon  system).  It  also  includes  a  sys¬ 
tematic  procedure  for  finding  operational  equipment  that  is  similar  to 
the  proposed  equipment. 

The  use  of  the  PAGES  model  may  assist  in  performance  of  the  com¬ 
parability  analysis.  This  model  estimates  the  number  of  technical  man¬ 
ual  pages  required  to  document  maintenance  tasks.  The  estimation  can 
then  be  used  for  comparison  with  similar  systems  or  subsystems. 

A  comparability  analysis  is  initiated  using  the  outline  of  the 
hardware/conf iguration/character istics  data  file  as  a  starting  point. 
The  comparability  concept  is  also  extended  to  address  software,  opera¬ 
tor  tasks,  and  training.  The  first  step  after  the  selection  of  a  base¬ 
line  system  is  to  identify  new,  eliminated,  or  reallocated  operational 
tasks  in  a  preliminary  task  list.  This  might  be  accomplished  by  a 
mock-up  task  analysis.  The  maintenance  training  and  operator  course 
material  data  files  are  then  established  using  comparable  training 
course  data  for  the  required  skills.  Course  and  task  data  are  used  in 
resource  assessment  to  estimate  training  requirements.  Other  informa¬ 
tion  which  may  be  used  to  assess  resources  such  as  facilities,  man¬ 
power,  and  system  ownership  cost  are  also  estimated  using  the  baseline 
comparison  system. 

Comparability  analysis  is  the  keystone  to  application  of  ASSET  in 
early  system  design.  Existing  documentation  outside  of  ASSET  provides 
a  procedure  for  applying  this  concept  to  hardware.  In  addition,  well- 
defined  data  sources  for  this  extended  information  must  be  identified 
and  require  searching  and  development  by  the  analyst  performing  the 
ASSET  application. 

2.3  LIFE  CYCLE  COST  ASSESSMENT  PROCEDURE 

The  life  cycle  cost  (LCC)  assessment  capability  within  ASSET  is 
provided  by  the  application  of  the  Reliability,  Maintainability  and 
Cost  Model  (RMCM).  The  value  of  life  cycle  cost  assessments  in  plan¬ 
ning  for,  or  in  designing  of,  a  weapon  system  has  been  established  and 
there  are  many  Life  Cycle  Cost  models  in  use.  There  are  many  ways  to 
accomplish  LCC  assessments  and  many  techniques,  models,  and  data  sys¬ 
tems  to  assist  in  its  accomplishment.  ASSET  presents  several  options 
within  the  RMCM  and  includes  the  information  contained  in  the  consolid¬ 
ated  data  base  to  provide  the  user  with  a  tool  for  LCC  analysis. 
Again,  the  option  used  depends  upon  the  specific  problem  being  invest¬ 
igated  and  the  analysis  technique  selected  for  application. 

In  addition  to  the  LCC  assessment  provided  by  the  RMCM,  informa¬ 
tion  provided  by  several  other  models  may  be  beneficial  for  a  parti¬ 
cular  application  program.  These  models  include: 

a.  Page  Estimating  Model. 

b.  Training  Requirements  Analysis  Model. 

c.  Personnel  Avai labi 1 i ty  Model . 
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Results  from  these  models  may  be  used  as  inputs  in  the  LCC 
assessment  when  other  data  is  not  available  or  may  be  used  to  validate 
data  collected  from  other  sources. 

The  life  cycle  cost  detail  provided  by  ASSET  is  comparable  to  that 
of  several  models  which  have  been  successfully  used.  Cost  adjustments 
and  perturbations  are  also  supported  by  the  ASSET  which  enables  various 
sensitivity  analyses  to  be  conducted. 

2.9  DESIGN  OPTION  DECISION  TREE  PROCEDURE 

The  Design  Option  Decision  Tree  (DODT)  is  an  existing  methodology 
which  is  documented  and  has  been  applied  in  the  study  of  several  pro¬ 
posed  and  existing  weapon  systems.  ASSET  includes  a  DODT  procedure 
which  interfaces  with  the  existing  DODT  methodology  and  injects  sup- 
portability  estimates  and  evaluations  to  assist  in  alternate  design 
and/or  support  decisions. 

All  eight  of  the  computer  models  associated  with  ASSET  may  be  used 
within  the  DODT  procedure.  These  models  address  supportabi 1 ity  con¬ 
siderations  useful  in  the  evaluation  of  alternatives  as  identified  in  a 
DODT.  Use  of  individual  models  is  an  option  of  the  analyst  and  is 
dependent  on  the  particular  requirements  of  an  application  program. 

The  design  option  decision  tree,  DODT,  provides  a  means  of 
accounting  for  the  many  trade-offs  that  are  performed  during  the  course 
of  a  system  design  effort  and  identifying  the  critical  decision  points 
during  design.  Specifically,  the  DODT  is  a  graphic  means  of  depicting 
the  sequence  of  engineering  decisions  required  for  resolution  of  a 
design  problem  and  describing  the  design  options  available  at  each  de¬ 
cision  point.  DODTs  can  be  prepared  to  various  levels  of  detail,  de¬ 
pending  upon  the  specific  problem  analysis  required.  A  complete  break¬ 
down  can  go  to  the  detailed  "hardware"  level;  however,  the  tree  can  be 
developed  to  whatever  level  of  detail  is  required  for  the  particular 
system. 

Some  factors  which  influence  the  decision  options  are  the  perform¬ 
ance  requirements  of  the  system,  logistics,  weight,  cost,  reliability, 
and  development  risk.  Human  resources  data,  related  to  personnel, 
training,  and  maintenance  impacts,  can  be  added  as  a  system  require¬ 
ment,  and  would  then  become  factors  in  the  choice  of  alternatives  and 
be  shown  on  the  DODT.  As  design  options,  these  data  can  include 
quantity  of  personnel  required  to  perform  maintenance  troubleshooting 
on  the  equipment,  job  specialty  of  the  maintenance  personnel,  time  to 
troubleshoot  a  failure  in  the  equipment,  ease  of  maintaining  the  equip¬ 
ment,  and  complexity  of  tools  required  to  perform  maintenance  work  on 
the  equipment. 

Within  the  DODT  format,  a  numerical  evaluation  scheme  can  be 
established  by  assigning  a  scale  rating  to  each  of  the  design  para¬ 
meters  of  interest,  including  weight,  actual  cost  in  dollars,  perform¬ 
ance,  development  risk,  human  resources,  and  logistics  support.  A 
scale  rating  can  be  given  to  each  branch  of  a  decision  node  of  the 
DODT.  These  numerical  scale  ratings  allow  a  quantitative  determinat ion 
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of  the  best  path  through  the  tree.  The  scale  rating  scheme  provides 
an  easily  implemented  method  for  the  designer  to  evaluate  choices 
within  the  DODT,  and  to  quantify  the  alternatives  involved  in  making 
design  decisions.  The  scale  ratings  for  each  of  the  areas  can  be 
derived  from  historical  data,  results  of  experiments,  or  mathematical 
modeling.  In  addition  to  the  scale  ratings  applied  to  the  design 
options  in  the  tree,  there  can  also  be  a  confidence  level  for 
feasibility  of  engineering  development  assigned  to  each  option  for  new 
technology  areas  both  in  design  as  well  as  in  related  support. 

DODTs  are  used  in  ASSET  to  depict  the  overall  system  and  critical 
subsystems.  The  general  system  level  is  important  because  the  trade¬ 
offs  normally  depicted  have  significant  life  cycle  impact  and  should  be 
performed  early  in  the  acquisition  process.  In  addition,  the  general 
system  tree  is  helpful  in  identifying  critical  subsystems. 

When  it  is  decided  to  use  DODTs,  subsystem  DODTs  should  be  de¬ 
veloped  as  early  as  possible  for  critical  subsystems.  These  critical 
subsystems  will  be  identified  during  system  design  and  are  usually 
critical  to  all  missions,  have  many  operating  elements,  receive  heavy 
use,  or  have  many  inherent  alternatives.  ASSET  extends  the  DODT  concept 
to  the  design  of  support  systems  and  a  logistics  option  tree  is  used 
for  each  system  to  document  the  baseline  approach  and  to  identify 
viable  alternative  logistics  concepts. 

In  a  trade  study  which  can  be  done  by  the  repeated  application  of 
the  ASSET  tools  and  techniques,  the  design  options  are  defined  in  de¬ 
tail,  and  analyzed  using  a  number  of  engineering  and  support  factors. 
Resolution  of  the  trade-off  is  achieved  by  mathematically  combining  the 
data  for  each  design  alternative  into  a  composite  score,  and  selecting 
the  alternative  with  the  "best  score".  This  leads  to  the  comparison  of 
alternatives  and  to  the  eventual  selection  of  a  design  approach. 

In  summary,  DODTs  provide  a  clear  method  of  showing  choices,  a 
traceable  record  of  decisions  made,  and  a  rationale  for  making  the  de¬ 
cisions.  The  DODT  approach  tends  to  indicate  that  all  relevant  deci¬ 
sion  paths  have  been  depicted  and  so  must  be  carefully  applied  to 
problems  that  can  be  bounded  by  a  DODT.  Depending  on  their  complex¬ 
ity,  a  significant  amount  of  labor  may  be  necessary  to  generate  elabor¬ 
ate  trees  containing  many  nodes  and  branches.  Each  problem  must  be 
reviewed  to  establish  the  requirements  for  and  the  benefits  to  be  de¬ 
rived  by  generating  and  using  DODTs.  The  DODT  must  be  applied  properly 
and  in  consideration  of  the  problem  under  evaluation.  The  technique 
works  with  ASSET  in  the  applications  where  the  problem  set  can  be 
properly  bounded  and  depicted  by  a  set  of  alternative  actions  and  de¬ 
cision  choices. 
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CHAPTER  3.  ASSET  MODELS  OVERVIEW 


This  chapter  of  the  ASSET  Applications  User's  Guide  contains  a 
generalized  overview  of  the  individual  computer  models  incorporated  in 
ASSET  to  facilitate  the  various  quantitative  analyses  required  by  the 
procedures. 

3.1  GENERAL 

Associated  with  ASSET  are  eight  computerized  models  which  support 
the  decision-making  processes.  These  models  are  listed  below: 

a.  Reliability  and  Maintainability  (RM)  Model. 

b.  Reliability,  Maintainability,  and  Cost  Model  (RMCM). 

c.  Training/Aiding  Matrix  (TAM)  Model. 

d.  Page  Estimating  (PAGES)  Model. 

e.  Training  Requirements  Analysis  Model  (TRAMOD). 

f.  Personnel  Avai labi 1 ity  Model  (PAM). 

g.  Logistics  Composite  Model  (LCOM). 

h.  Expected  Value  Model  (EXPVAL). 

The  first  six  models  listed  were  developed  in  support  of  avionics 
design  efforts.  These  have  been  modified  and  are  incorporated  for 
ASSET  application.  The  last  two  models  listed  were  developed  independ¬ 
ently  and  presently  are  accepted  and  utilized  in  the  logistics  commun¬ 
ity. 


The  analytical  computer  models  are  tools  which  may  be  used  in 
varying  combinations  during  the  performance  of  the  ASSET  procedures. 
Figure  1-6  shows  the  interrelationship  between  the  ASSET  procedures  and 
computer  models.  This  is  presented  as  a  suggested  guide  for  viewing 
the  ASSET  methodology  framework  and  may  be  modified  for  individual 
application  program  requirements.  The  selection  of  individual  models 
for  use  in  a  particular  application  program  is  an  option  of  the  user. 

The  synthesis  of  the  procedures  and  computer  model  tools  into  a 
unified  ASSET  application  defined  by  the  user  permits  the  accomplish¬ 
ment  of  the  ASSET  goals  identified  early  in  Chapter  1. 

The  following  paragraphs  describe  each  of  the  eight  computer 
models  and  identify  the  procedure(s)  which  may  benefit  from  the  use  of 
these  tools. 


PROCEDURES 


Figure  1-6.  ASSET  Procedure  -  Model  Correlation  W482-520-063 


3.2  RELIABILITY  AND  MAINTAINABILITY  (RM)  MODEL 


The  Reliability  und  Maintainability  (RM)  Model  provides  outputs  of 
R&M  parameter-*  in  a  form  useful  for  initial  studies  and  trade-off 
analyses  in  the  conceptual  acquisition  phase.  The  input  consists  of 
reliability  and  maintainability  parameters  of  the  weapon  system.  The 
output  includes  information  useful  to  the  system  designer  in  identify¬ 
ing  high  support  resource  consumption  areas  upon  which  to  focus  cost 
reduction  system  design  efforts.  In  view  of  the  fact  that  system  sup¬ 
port  factors  affect  a  significant  portion  of  the  system  life  cycle 
cost,  the  RM  model  focuses  on  calculating  estimates  of  mean-time-to- 
repair  (MTTR),  maintenance  manhours,  and  system  and  subsystem  avail¬ 
ability  based  on  the  underlying  system  and  support  concept. 

The  RM  model  provides  useful  information  for  the  performance  of 
the  following  procedures: 

a.  Maintenance  Action  Network  Procedure. 

b.  Integrated  Task  Analysis  Procedure. 

c.  Logistic  Resources  Assessment  Procedure. 

d.  Design  Option  Decision  Tree  Procedure. 

The  model  verifies  the  assignments  of  factors  on  the  branches  of 
the  maintenance  action  network  and  provides  measurements  of  resource 
usage  for  task  analysis  and  resource  assessment.  The  model  may  also  be 
valuable  in  quantifying  advantages  of  alternate  options  in  a  DODT 
appl icat ion. 

Rapid  computational  ability  was  a  primary  design  feature  of  the  RM 
model  because  numerous  trade-off  studies  are  conducted  during  the 
development  of  new  avionics  systems  and,  therefore,  many  iterations  of 
the  model  would  be  needed.  This  was  accomplished  by  designing  an  aver¬ 
age  value  model.  Total  demands  on  the  support  system  are  computed  by 
multiplying  the  average  support  resources  required  per  event  by  the 
average  frequency  of  event  occurences  and  then  summing  across  all  main¬ 
tenance  events  associated  with  the  equipment  (or  system)  repair. 

In  order  to  use  the  RM  model,  it  is  necessary  to  start  with  a 
system  . , eakdown  structure  (hierarchy)  with  up  to  five  levels  of  inden¬ 
ture  selected  by  the  model  user  (see  figure  1-7).  The  selection  must 
be  made  with  care  to  ensure  that  the  indenture  levels  are  consistent 
across  the  system  and  that  aggregation  of  data  is  meaningful  for  the 
specific  levels. 

The  next  step  is  to  model  the  operation  and  maintenance  ( O&M)  pro¬ 
cess.  Due  to  the  requirement  for  computational  speed,  the  R&M  model 
was  based  upon  a  simplified  representation  of  that  process.  Basically, 
the  operational  scenario  creates  a  demand  upon  the  maintenance  system 
as  a  function  of  the  number  of  sorties  or  flying  hours  and  the  failure 
rates  of  the  individual  subsystems  or  units  in  the  avionics  suites. 
The  PM  model  computes  the  demand  placed  on  the  maintenance  system  on  a 


SYSTEM 
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Figure  1-7.  Example  of  Avionics  Suite  Hierarchy 

subsystem  or  LRU  basis,  and  therefore  treats  the  operational  scenario 
in  terms  of  the  mean  flying  hours  between  maintenance  actions  of  in¬ 
dividual  LRUs.  This  mean  value  of  demand  on  the  maintenance  system  is 
for  assessment  of  life  cycle  support  resources  during  the  initial 
phases  of  the  acquisition  process. 

Given  that  a  demand  is  placed  upon  the  maintenance  system,  the 
maintenance  process  must  restore  the  equipment  to  operational  readi¬ 
ness.  The  maintenance  process  is  modeled  in  terms  of  on-equipment  and 
off-equipment  events.  The  maintenance  process  is  initiated  by  a  dis¬ 
crepancy  report  or  indication  on  the  part  of  the  aircrew  or  maintenance 
personnel  that  a  malfunction  exists.  The  model  distinguishes  between 
actual  failures  and  human  (or  equipment)  errors  which  later  result  in  a 
"cannot  duplicate"  (CND)  condition.  However,  since  both  result  in  a 
demand  for  maintenance  resources,  the  failure  frequency  is  based  on  all 
discrepancy  reports  which  trigger  subsequent  maintenance  events  on  the 
flightline. 
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The  model  considers  generic  events  consisting  of  one  or  more  main¬ 
tenance  functions  (i.e.,  adjust,  align,  calibrate,  troubleshoot,  in¬ 
spect,  operate,  remove/install,  repair,  service,  etc.)*  The  support 
resources  associated  with  each  maintenance  function  are  also  aggregated 
at  the  event  level.  Although  not  precisely  adjusted  for  each  detail, 
results  are  sufficient  for  the  purpose  of  assessing  support 
requirements  in  the  early  stages  of  the  system  acquisition  process. 
The  possible  flightline  maintenance  events  are: 

a.  Set  up  flightline  support  equipment. 

b.  Troubleshoot. 

c.  Troubleshoot  a  cannot  duplicate  (CND)  discrepancy. 

d.  Remove  and  replace. 

e.  Minor  repair  on  the  equipment. 

f.  Verify  replacement  correcting  discrepancy. 

g.  Verify  minor  on-equipment  repair  correcting  discrepancy. 

Support  resources  required  per  event  at  each  level  must  be 
provided  as  inputs  to  the  RM  model.  They  are  defined  in  terms  of  crew 
size,  specialty  codes,  skill  levels,  support  equipment,  and  average 
time  required  to  complete  the  tasks  associated  with  the  event. 

The  detailed  reliability  and  maintainability  information  can  be 
expressed  in  terms  useful  to  system  designers  during  the  early  phases 
of  system  acquisition.  The  fundamental  concept  is  to  define  a  measure 
of  support  resource  requirements,  evaluate  this  measure  for  each  ele¬ 
ment  of  the  total  system,  and  then  rank  each  element  in  the  system  in 
terms  of  the  measure.  The  ranking  identifies  the  relative  impact  of 
each  element  in  the  system  on  support  requirements.  This  information 
focuses  the  designer's  attention  on  potential  problem  areas  so  that 
action  can  be  taken  to  avoid  future  costs. 

Three  measures,  called  figures  of  merit  (FOMs),  are  calcuated  by 
the  model.  These  are  (1)  mean  time  to  repair  (MTTR)  per  1000  flight 
hours,  (2)  maintenance  manhours  (MMH)  per  1000  flight  hours,  and  (3) 
flightline  system  availability.  The  first  two  FOMs  are  utilized  to 
measure  the  impact  on  maintenance  resource  requirements,  while  the 
third  measures  the  maintenance  impact  on  operational  readiness.  These 
FOMs  are  sufficient  for  most  analyses  although  other  metrics  could  be 
developed  to  enhance  the  model  capability.  Some  FOMs  which  should  be 
considered  are  support  equipment  utilization,  logistics  downtime,  turn¬ 
around  time,  or  sparing  effectiveness. 

The  underlying  maintenance  structure  in  the  RM  model  is  based  on 
generalized  maintenance  action  networks.  The  following  is  a  brief 
description  of  this  process. 
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The  initial  maintenance  event  is  to  set  up  the  necessary  test 
equipment  and  power  sources  at  the  flightline  and  exercise  the  subsys¬ 
tem  that  has  a  discrepancy.  If  a  failure  has  occurred,  a  troubleshoot¬ 
ing  event  will  locate  the  cause  of  the  malfunction.  In  some  instances, 
the  apparent  failure  cannot  be  duplicated  and  the  maintenance  activity 
will  terminate  as  a  cannot  duplicate  (CND)  disposition.  The  flightline 
troubleshooting  event  normally  isolates  the  malfunction  to  a  line  re¬ 
placeable  unit  (LRU).  Depending  on  the  nature  of  the  malfunction,  it 
may  be  necessary  to  remove  an  LRU  and  send  it  to  the  field  shop  for 
repair.  If  this  is  done,  the  aircraft  is  put  back  into  service  by 
replacing  the  faulty  unit  with  a  functioning  one  from  spares  stock. 
Alternatively,  it  may  be  possible  to  effect  the  needed  repair  on  the 
aircraft  by  a  minor  maintenance  activity  such  as  alignment,  calibra¬ 
tion,  etc.  In  either  case,  a  verification  event  is  required  to  provide 
assurance  that  the  procedure  has,  in  fact,  corrected  the  problem. 

Two  sets  of  mutually  exclusive,  parallel  events  have  been  noted 
above  for  on-equipment  maintenance.  In  terms  of  the  utilization  of 
maintenance  resources,  it  is  necessary  that  the  probabilities  of  these 
parallel  events  be  determined.  Furthermore,  since  the  events  are  mutu¬ 
ally  exclusive,  the  sum  of  the  probabilities  of  each  pair  of  parallel 
events  will  equal  unity. 

While  on-equipment  maintenance  is  concerned  basically  with  the 
system  repair,  shop  maintenance  (off -equipment)  deals  with  individual 
LRUs  removed  from  the  aircraft.  The  resources  demanded  at  this  mainte¬ 
nance  level  are  also  functions  of  failure  frequency.  This  is  indicated 
by  the  LRU  fault  occurrences  given  in  maintenance  actions  per  flight 
hour.  The  possible  maintenance  events  that  can  be  conducted  at  the 
intermediate  shop  will  then  be: 

a.  LRU  bench  check  and  repair. 

b.  LRU  bench  check  OK  (shop  CND). 

c.  LRU  not  repairable  this  station  (NRTS). 

The  LRU  bench  check  and  repair  encompasses  a  troubleshooting 
activity  as  well  as  subsequent  part  replacement,  calibration, 
adjustment,  and  additional  functions  necessary  to  bring  the  LRU  to  full 
operating  status.  The  shop  CND  result  which  sometimes  occurs  is  due  to 
the  fact  that  fault  isolation  at  the  flightline  is  imperfect  and  may 
lead  to  a  functioning  LRU  being  sent  to  the  shop.  On  the  other  hand, 
the  flightline  procedures  may  only  isolate  the  malfunction  to  a  group 
of  LRUs  so  that  all  have  to  be  sent  to  the  shop. 

The  not  repairable  this  station  (NRTS)  disposition  is  used  to  de¬ 
scribe  the  maintenance  event  which  results  in  shipping  a  unit  to 
another  maintenance  echelon  where  greater  capability  exists  for  testing 
and  repair.  The  units  shipped  may  be  either  LRUs  or  shop  replaceable 
units  (SRUs).  If  the  intermediate  shop  does  not  have  the  capability  to 
maintain  a  specific  LRU,  it  will  be  shipped  to  depot.  In  other  in¬ 
stances,  the  base  shop  will  remove  and  replace  malfunctioning  SRUs 


which  will  then  be  shipped  to  the  appropriate  depot  if  they  cannot  be 
serviced  at  the  base. 

3.3  RELIABILITY,  MAINTAINABILITY,  AND  COST  MODEL  (RMCM) 

The  Reliability,  Maintainability,  and  Cost  Model  (RMCM)  estimates 
life  cycle  costs  of  weapons  systems.  A  primary  feature  of  the  RMCM  is 
that  it  is  operated  interactively  from  a  computer  terminal  and  allows 
the  user  to  perturb  data  for  instantaneous  sensitivity  analysis. 

The  RMCM  calculates  a  life  cycle  cost  (LCC)  value  for  the  weapon 
system  defined  to  the  model  through  a  set  of  equipment,  reliability, 
maintainability  and  cost  factors.  The  LCC  value  may  be  useful  for  com¬ 
parison  and  evaluation  in  the  performance  of  the  following  procedures: 

a.  Maintenance  Action  Network  Procedure. 

b.  Integrated  Task  Analysis  Procedure. 

c.  Logistic  Resources  Assessment  Procedure. 

d.  Life  Cycle  Cost  Assessment  Procedure. 

e.  Design  Option  Decision  Tree  Procedure. 

RMCM  consists  of  distinct  elements  that  have  been  chosen  to  cap¬ 
ture  relevant  costs  associated  with  investment,  operation,  and  support 
of  a  system.  The  model  applies  cost  factors  to  the  assessed  resource 
values  generated  by  algorithms  from  the  RM  model  and  then  combines  the 
results  with  other  cost  elements  and  cost  algorithms  to  estimate  total 
LCC.  The  outputs  are  presented  in  selected  combinations  or  summary 
form  as  requested  by  the  user.  The  cost  elements  represent  a  complete 
set  of  factors  that  are  required  to  accurately  evaluate  life  cycle 
costs . 

The  cost  elements  are  aggregated  by  a  major  cost  category  struc¬ 
ture  with  three  principal  cost  categories  —  nonrecurring,  recurring, 
and  system  disposal.  Although  system  disposal  is,  by  definition,  a 
nonrecurring  cost,  such  costs  are  considered  separately  by  the  model. 
The  hierarchical  structure  of  these  cost  elements,  in  terms  of  their 
contributions  to  the  LCC  categories  used  to  catalog  them,  is  shown  in 
figure  1-8. 

The  interactive  RMCM  program  performs  four  major  functions:  R&M 
computation,  cost  computation,  R&M  perturbation,  and  cost  perturbation. 
After  preparing  R&M  and  cost  data  banks,  the  user  exercises  the  model 
in  one  of  several  operational  modes  which  uses  a  combination  of  the 
functions  listed  above.  The  simplest  mode  of  operation  is  the  basic 
computation  of  reliability,  maintainability,  and  cost  output  para¬ 
meters.  The  input  R&M  parameter  values,  the  same  as  those  utilized  by 
the  R&M  model,  and  cost  factor  values  from  the  cost  data  bank  are  used 
as  inputs  to  the  cost  equations.  Cost  outputs  are  then  calculated 
using  the  cost  algorithms  and  are  available  to  the  user  through  the 
interactive  terminal  or  through  the  batch  mode  print  program. 
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To  study  the  sensitivity  of  an  R&M  parameter  on  LCC,  the  user  may 
alter  an  R&M  parameter  and  create  a  second  "perturbed"  R&M  file.  The 
cost  equations  are  then  evaluated  for  both  configurations  simultane¬ 
ously,  with  comparative  outputs  available  to  the  user.  Similarly,  it 
is  possible  to  vary  cost  parameters.  The  user  may  modify  any  variable 
from  the  cost  data  file,  any  output  from  the  R&M  computations,  or  any 
combination  of  both  prior  to  calculation  of  the  cost  outputs. 
Finally,  both  the  R&M  and  the  cost  files  can  be  perturbed  when  perform¬ 
ing  sensitivity  and  trade-off  analyses.  The  resulting  perturbed  out¬ 
puts  reflect  the  combined  effects  of  changes  in  both  R&M  and  cost 
values  relative  to  the  baseline  (original  data)  outputs.  The  sensitiv¬ 
ity  analysis  capability  is  convenient  for  making  ready  comparisons  and 
can  provide  visibility  for  the  various  tradeoff  considerations. 

3.4  TRAINING/AIDING  MATRIX  (TAM)  MODEL 

The  Training/Aiding  Matrix  (TAM)  presents  an  assessment  of  train¬ 
ing  and  technical  manual  information  relevant  to  the  acquisition  of  a 
weapon  system  or  subsystem.  TAM  provides  information  content  require¬ 
ments  in  terms  of  the  degree  of  coverage  required  in  training  and/or 
technical  manuals  for  both  flightline,  troubleshoot  and  non-trouble- 
shoot,  plus  shop  repair  tasks.  The  output  of  the  TAM  program  consists 
of  the  training/aiding  matrix.  The  elements  of  this  matrix  are  ratios 
of  the  weight  of  the  training  requirements  to  the  technical  manual  re¬ 
quirements  (sometimes  referred  to  as  the  head-book  trade-off). 

The  training  and  technical  manual  content  information  provided  by 
the  TAM  model  may  be  useful  in  the  following  ASSET  procedures: 

a.  Integrated  Task  Analysis  Procedure. 

b.  Logistic  Resources  Assessment  Procedure. 

c.  Design  Option  Decision  Tree  Procedure. 

The  TAM  technique  is  embodied  in  a  program  which  is  a  collection 
of  algorithms  utilized  to  present  the  training  and  technical  manual  in¬ 
formation.  This  information  is  presented  in  a  matrix  format  with  the 
system  hardware  hierarchy  forming  the  rows  of  the  matrix  and  three 
basic  types  of  tasks  forming  the  columns.  These  tasks  are  troubleshoot 
on  the  flightline,  non-troubleshoot  on  the  flightline,  and  repair  in 
the  shop.  The  first  two  are  considered  at  the  subsystem  level.  The 
third  is  considered  at  the  LRU  level.  The  degree  of  information  cover¬ 
age  for  training  and  technical  manuals  appears  as  a  ratio  read  as  the 
training  requirements  versus  the  technical  manual  requirements.  A  one 
(1)  indicates  light  coverage  required  in  either  area,  while  a  three  (3) 
indicates  heavy  coverage. 

The  TAM  program  is  an  interactive  program  requiring  basic  input 
data  to  be  provided  by  the  user.  This  data  consists  of  the  name  of  the 
system  under  analysis  and  the  number  cf  subsystems  and  LRUs  in  the  sys¬ 
tem  along  with  the  names  of  the  subsystems  and  LRUs.  In  addition,  the 
user  must  provide  numerical  information  corresponding  to  the  three 
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Figure  1-8.  Life  Cycle  Cost  Hierarchy 
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types  of  maintenance  tasks  --  flightline  troubleshooting,  non-trouble¬ 
shooting,  and  shop  repair  —  to  be  used  in  statistical  analysis  in 

ranking  each  task.  After  this  data  is  provided  to  the  program  for  each 
subsystem  and  LRU,  the  user  is  requested  to  answer  questions  posed  by 
the  program  relating  to  the  statistical  analysis  and  ranking  of  each 
task. 

The  assessment  of  training  and  technical  manual  information  con¬ 
tent  has  typically  been  accomplished  in  the  mid-  to  full-scale  de¬ 
velopment  phase.  ASSET  encourages  the  earlier  initiation  of  investiga¬ 
tion  in  this  area  through  the  integrated  task  analysis  procedure. 
There  are  advantages  to  assessing  training  and  technical  manual  in¬ 
formation  content  earlier  during  the  acquisition  program.  Such  an 

assessment  could  be  used  to: 

a.  Prioritize  the  training  and  technical  manual  coverage  areas. 

b.  Develop  training  and  technical  manual  statements  of  work. 

c.  Alert  training  and  technical  manual  specialists  to  the  pos¬ 
sibility  of  extraordinary  product  needs. 

d.  Identify  areas  for  training/technical/support  equipment 

tradeoffs. 

3.5  PAGE  ESTIMATING  (PAGES)  MODEL 

The  technical  manual  page  estimating  model  (PAGES)  is  used  to 

determine  the  quantity  and  types  of  pages  that  will  be  required  for 
both  flightline  and  shop  technical  manuals  in  support  of  a  weapon  sys¬ 
tem.  Inputs  to  the  model  are  the  type  of  system  and  number  of  compos¬ 
ite  subsystems,  LRUs  and  SRUs.  Output  results  are  estimates  of  the 
total  page  requirements  and  are  qualified  as  troubleshooting  or  non¬ 
troubleshooting  pages  such  as  those  found  in  a  checkout  procedure. 

The  technical  manual  page  estimates  provided  by  the  PAGES  model 
may  be  useful  in  analyses  conducted  within  the  following  procedures: 

a.  Integrated  Task  Analysis  Procedure. 

b.  Logistic  Resources  Assessment  Procedure. 

c.  Comparability  Analysis  Procedure. 

d.  Life  Cycle  Cost  Procedure. 

e.  Design  Option  Decision  Tree  Procedure. 

The  page  estimates  are  particularly  valuable  when  comparing  al¬ 
ternate  system  designs. 


The  model  algorithms  are  unique  to  an  equipment  category;  hence,  a 
set  of  algorithms  is  included  for  electrical  and  another  for 
mechanical /hydraul ic  systems.  The  user  selects  the  appropriate 
algorithm  by  answering  a  user  prompt  with  the  type  of  system  under 
analysis,  either  electrical,  mechanical,  or  both. 

The  output  of  PAGES  is  an  estimation  of  the  number  of  technical 
manual  pages  that  will  be  required  for  both  the  flightline  and  the 
intermediate  shop  level.  The  estimate  is  presented  in  a  matrix  format 
with  the  type  of  page  forming  the  rows  and  the  type  of  maintenance  task 
forming  the  columns.  The  page  type  includes  those  shown  in  figure  1-9. 
The  types  of  maintenance  tasks  are  flightline  troubleshooting,  shop 
troubleshooting,  flightline  non-troubleshooting,  and  shop  non-trouble¬ 
shooting. 

A  separate  estimation  matrix  is  produced  for  each  of  the  following 
classifications  of  technical  manuals  and  systems  as  specified  by  the 
user: 

a.  Electronics  -  conventional. 

b.  Electronics  -  task-oriented. 

c.  Mechanical/Hydraulic  -  conventional. 

d.  Mechanical/Hydraulic  -  task-oriented. 
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Figure  1-9.  Technical  Manual  Page  Types  Included  in  PAGES 


The  model  may  be  used  to  estimate  either  conventional  or  task- 
oriented  manuals.  The  conventional  manual  contains  significant  theory 
and  is  of  the  general  kind  procured  by  the  Air  Force  ever  the  last  15 
years.  The  task-oriented  manual  is  a  newer  type  which  is  directive  in 
nature  and  is  specified  by  MIL-M-83495. 

The  technical  manual  page  estimating  model  is  a  tool  for  use  dur¬ 
ing  the  evaluation  of  a  new  system  acquisition  for  the  effect  on  tech¬ 
nical  manual  requirements.  In  addition,  this  program  may  be  useful  in 
the  initial  preparation  of  technical  manual  proposals  and  in  the  evalu¬ 
ation  of  these  proposals. 

The  PAGES  model  require  additional  verification/validation  to 
evaluate  the  applicability  of  the  underlying  estimating  algorithms  to 
various  levels  of  equipment  complexity.  Thus,  the  user  must  be 
cautioned  to  review  the  model  assumptions  and  algorithms  before  using 
this  model.  This  may  be  accomplished  referencing  Book  II,  Chapter  4  of 
this  guide  for  more  detailed  information  on  the  PAGES  model. 

3.6  TRAINING  REQUIREMENTS  MODEL  (TRAMOD) 

Analysis  of  training  impacts  within  the  acquisition  process  is 
deemed  an  absolute  necessity  if  weapon  systems  are  to  be  designed  to 
provide  essential  capability  at  minimum  affordable  cost.  TRAMOD  can 
facilitate  the  rapid  estimation  of  training  requirements  and  the  conse¬ 
quences  of  alternative  approaches  to  fulfilling  them.  The  model  pro¬ 
vides  an  aid  to  weapon  system  designers  and  planners  in  considering  the 
training  implications  of  design.  Equally  important,  TRAMOD  permits  the 
training  analyst  to  better  understand  and  quantify  the  impacts  of  new 
systems  on  training  requirements  and  the  options  available  to  fulfill 
them,  in  terms  of  the  effects  of  the  design  and  maintenance  character¬ 
istics  of  equipment.  This  information  can  then  be  used  to  influence 
the  design  process.  Iterative  use  of  the  model,  with  systematic  manip¬ 
ulation  of  constraint  parameters,  can  refine  results  and  enable  the 
user  to  examine  various  concepts.  In  this  way,  TRAMOD  can  accomplish 
early  identification  of  excessive  requirements,  investigation  of  alter¬ 
native  policy  decisions,  and  training  cost  estimation.  Used  early  in 
system  development,  this  capability  aids  in  avoidance  of  unnecessary 
training  expenditures  by  allowing  a  user  to  approach  the  solution  of 
training  problems  in  terms  of  their  causes. 

Training  analysis  provided  by  the  TRAMOD  may  be  beneficial  in  sup¬ 
port  of  analyses  conducted  during  the  following  procedures: 

a.  Integrated  Task  Analysis  Procedure. 

b.  Logistic  Resources  Assessment  Procedure. 

c.  Life  Cycle  Cost  Assessment  Procedure. 

d.  Design  Option  Decision  Tree  Procedure. 


TRAMOD  requires  input  data  relating  to  the  tasks  to  be  performed 
on  the  weapon  system.  The  data  is  fairly  detailed  with  each  task  being 
assigned  a  SCALAR  value  for  each  of  five  characteristics  denoting  fre¬ 
quency,  criticality,  learning  difficulty,  and  psychomotor  and  cognitive 
levels.  The  model  results  describe  potential  training  plans  and 
scenarios. 

The  training  model,  TRAMOD,  consists  of  four  main  components: 

a.  Training  block  generator. 

b.  Training  plan  generator. 

c.  Training  program  generator. 

d.  Training  analyst. 

Figure  I -10  illustrates  the  main  components  of  the  training  model 
concept.  The  TRAMOD  analysis  begins  by  using  pre-established  criteria 
to  select  task  blocks  that  require  training.  The  second  component  in 
the  model  generates  the  training  plan,  consisting  of  the  following: 
task  blocks  to  be  trained,  type  of  training  each  will  receive,  i.e., 
school  or  on  the  job  training  (OJT ) ,  and  recommended  methods  and  media 
for  training  each  task  block.  The  third  model  component  uses  the 
training  plan  to  construct  the  training  program  which  indicates  a  sche¬ 
dule  for  training  and  the  resulting  resource  requirements.  The  fourth 
component  required  for  successful  development  of  a  training  program  is 
the  training  analyst.  This  "man  in  the  loop"  feature  provides  the 
feedback  that  enables  the  process  to  become  self-correcting.  The  user 
is  able  to  examine  the  intermediate  outputs  of  the  training  model  and 
react  to  unanticipated  variations  or  repeated  irregularities  in  the 
procedure. 

Operation  of  the  model  is  based  upon  the  establishment  of  a  data 
bank  containing  the  list  of  tasks  to  be  performed.  Their  level  of 
specificity  is  a  user-defined  variable  allowing  for  flexibility  of  task 
definition.  Each  task  should  be  assigned  a  SCALAR  value  for  each  of 
five  task  characteristics  denoting  frequency,  criticality,  learning 
difficulty,  and  psychomotor  and  cognitive  levels.  The  requirement  for 
this  fairly  detailed  and  descriptive  data  for  tasks  performed  on  the 
system  is  a  constraint  on  the  timing  of  model  usage  within  an  acquisi¬ 
tion  program. 

TRAMOD  was  designed  with  interactive  program  controls  in  order  to 
give  the  user  the  greatest  amount  of  control  over  its  execution.  In 
addition  to  data  inputs,  its  operation  calls  for  several  interactive 
inputs.  TRAMOD  prints  a  request  for  them  as  they  are  needed,  and  reads 
input  from  the  terminal  in  a  free  format.  This  prevents  the  possibil¬ 
ity  of  an  aborted  computer  run  due  to  faulty  data  and  appreciably 
lessens  the  amount  of  preparatory  work  required  of  the  user.  It  also 
helps  the  user  to  develop  a  more  complete  understanding  of  the  effects 
of  individual  data  items  on  training  model  results. 
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Figure  I -10 .  Elements  of  Training  Requirements  Analysis  Model 


The  interactive  nature  of  TRAMOD  allows  for  flexibility  in  its 
operation  by  permitting  a  variety  of  options  to  meet  the  needs  of  dif¬ 
ferent  training  policies  and  designs.  Whenever  the  program  reaches  a 
point  where  a  decision  is  required  in  order  to  continue  execution,  a 
message  to  the  user  is  printed.  The  program  identifies  the  possible 
options  and  waits  for  the  user's  input,  such  as  the  screening  algorithm 
choice  required  to  establish  the  users's  task  selection  criteria. 
There  are  also  occasions  where  the  user  is  offered  the  option  of  chang¬ 
ing  default  values  for  data,  such  as  methods  and  media  mappings. 

Iterative  use  of  TRAMOD  lets  the  user  direct  the  program  to  repeat 
analyses,  both  within  and  among  the  major  components  of  the  model. 
This  control  gives  the  user  the  added  capability  of  identifying  the 
sensitivities  of  the  various  options  and  parameter  values.  Through 
examining  the  relative  effects  of  input  data  changes,  the  user  can 
identify  those  elements  of  design  and  policy  which  could  develop  into 
problems  in  the  planning  of  training.  This  feature  makes  the  model  an 
excellent  research  tool  for  the  training  analyst  interested  in  iden¬ 
tifying  the  potential  training  consequences  of  design  options  for  a  new 
weapon  system. 


3.7  PERSONNEL  AVAILABILITY  MODEL  (PAM) 

The  Personnel  Availability  Model  (PAM)  is  a  predictive  model  that 
provides  estimates  of  the  numbers  of  personnel  in  specific  Air  Force 
Specialty  Codes  (AFSCs)  at  user-specified  future  dates.  At  present, 
PAM  is  limited  to  projections  involving  13  selected  maintenance  AFSCs, 
listed  in  figure  I -1 1 .  These  AFSCs  are  defined  internally  in  the  pro¬ 
gram  and  cannot  be  altered  by  the  user. 

PAM  calculates  career  transition  activity  within  the  Air  Force  by 
a  series  of  transition  processes,  each  depicting  a  category  of  airmen 
defined  by  AFSC,  years  of  service  and  paygrade.  Probabilities  of 
transition  are  based  on  actual  transition  activity  data  contained  in 
the  Uniform  Airman  Record  (UAR). 

The  use  of  PAM  results  in  a  forecasting  of  personnel  available  in 
an  AFSC  of  interest.  This  information  may  be  useful  in  the  performance 
of  the  following  procedures: 

a.  Integrated  Task  Analysis  Procedure. 

b.  Logistic  Resources  Assessment  Procedure. 

c.  Life  Cycle  Cost  Assessment  Procedure. 
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d.  Design  Option  Decision  Tree  Procedure. 

Basically,  PAM  operates  on  UAR  data  to  project  future  career 
transition  activity  on  the  basis  of  occurrences  in  the  past.  The  re¬ 
sults  are  processed  to  yield  "snapshot"  descriptions  of  the  total  force 
composition  at  user-selected  intervals.  The  PAM  data  bank  presently 
contains  a  selection  of  data  elements  from  the  1975  and  1976  UAR  files 
for  approximately  95,000  airmen  assigned  to  the  13  AFSCs. 

Career  transition  activity  within  the  Air  Force  is  calculated  by  a 
series  of  Markov  processes,  each  depicting  a  population  of  airmen  with 
states  defined  by  years  of  service  (YOS)  and  paygrade.  Transition 
probabilities  are  calculated  on  the  basis  of  actual  transition  activity 
data  contained  in  the  UAR.  Populations  may  be  defined  on  particular 
airman  attributes  such  as  AFSC  designation,  or  analytically  established 
by  applying  a  discrete  dependent  variable  regression  analysis 
technique. 

The  model  examines  the  change  in  state  population  over  a  one-year 
period  and  calculates  the  transition  probabilities  of  upgrade,  incre¬ 
ment  (in  YOS  without  change  in  paygrade),  loss  from  service,  and 
transfer  which  are  stored  in  a  state  and  probability  data  base.  With 
this  data  base,  future  state  populations  can  be  determined  by  consider¬ 
ing  the  transition  dynamics.  Transition  into  a  state  occurs  in  one  of 
three  ways: 
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AFSC 

325X0 

325X1 

328X0 

328X1 

328X4 

423X0 

423X1 

423X3 

423X4 

426X2 

431X1C 

431X1E 

531X3 


SPECIALTY  DESCRIPTION 

Automatic  Flight  Control  Systems 

Instrument  Systems 

Avionic  Cormiunications 

Avionic  Navigation  Systems 

Inertial  and  Radar  Navigation  Systems 

Aircraft  Electrical  Systems 

Environmental  Systems 

Fuel  Systems 

Pneudraulic  System 

Jet  Engines 

Aircraft  Maintenance  (Jet,  over  2  engines) 
Aircraft  Maintenance  (Jet,  1  and  2  engines) 
Airframe  Repair 


Figure.  1-11.  Air  Force  Specialty  Codes  Used  in  PAM 


a.  A  trjrv.fer  from  same  other  AFSC  or  a  new  accession  into  the 

system. 

b.  An  incre.-.sf’  In  paygrade  with  an  incremental  increase  in  YOS. 

c.  An  incremental  increase  in  YOS  without  a  change  in  paygrade. 

The  PAM  operation  assumes  that  state  transfer  probabilities  are 
constant  for  each  state  transfer  within  a  personnel  availability  pro¬ 
jection.  The  user  is  allowed  to  make  projections  based  solely  on 
historical  data  or  to  make  the  desired  projections  on  historical  data 
modified  to  reflect  known  or  expected  changes  in  the  Air  Force  person¬ 
nel  po I  icy. 

PAMs  utility  is  limited  in  several  ways: 

a.  Fixed  embedded  personnel  data  for  the  years  1975-1976. 

b.  A  single  transition  period  projection. 

c.  Low  confidence  in  extended  years  projection. 

d.  Limited  embedded  AFSC  data  subject  to  obsolescence. 

e.  Unpredictable  external  influencing  factors. 

f.  Skill  identification  uncertainties. 

g.  Variable  experience  indicators. 

The  analyst  using  PAM  can,  however,  use  the  services  of  an  experi¬ 
enced  personnel  specialist  to  examine  outputs  and  to  input  current 
judgments  that  could  make  the  PAMs  output  more  useful  relative  to  the 
acquisition's  current  year. 

3.8  LOGISTICS  COMPOSITE  MODEL  (LCOM) 

The  Logistics  Composite  Model  (LCOM)  is  one  of  two  models  which 
have  been  well-established  in  the  modeling  community  and  incorporated 
into  ASSET.  LCOM  is  a  dynamic  simulation  program,  which  is  used  to 
assess  maintenance  manpower  and  support  equipment  requirements.  LCOM 
is  a  Monte  Carlo  model  and  thus  is  sensitive  to  the  dynamics  of  the 
operational  scenario.  The  output,  therefore,  may  be  used  to  identify 
peak  and  minimum  requirement  periods.  The  simulation  may  then  be  used 
to  evaluate  trade-offs  such  as  revised  operational  scheduling  or  in¬ 
creased  manpower.  LCOM  is  based  directly  on  the  informaton  from  a 
maintenance  action  network  and  operations  schedule  data.  The  basic 
output  of  the  simulation  is  the  performance  summary  report  which  is 
used  to  assess  maintenance  manpower  and  support  equipment  requirements. 
There  are  also  several  auxiliary  reports  that  may  be  obtained  as 
required. 
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The  use  of  LCOM  may  be  beneficial  in  the  following  procedures: 

a.  Maintenance  Action  Network  Procedure. 

b.  Integrated  Task  Analysis  Procedure. 

c.  Logistic  Resources  Assessment  Procedure. 

d.  Design  Option  Decision  Tree  Procedure. 

LCOM  is  a  simulation  model  used  to  represent  an  operational 
scenario.  The  data  required  by  this  representation  may  impede  the  use 
of  this  model  in  the  conceptual  phase  of  an  acquisition.  When  the 
necessary  data  is  available,  LCOM  is  a  very  useful  tool. 

3.9  EXPECTED  VALUE  (EXPVAL)  MODEL 

The  Expected  Value  Model  (EXPVAL)  is  the  second  of  two  models 
which  have  been  established  in  the  modeling  community  and  incorporated 
into  ASSET.  EXPVAL  is  an  average  value  model,  as  opposed  to  the  LCOM 
simulation  model,  used  to  assess  logistic  resources  such  as  maintenance 
manpower  and  support  equipment  requirements.  EXPVAL  is  usually 
exercised  in  conjunction  with  LCOM.  Input  consists  of  a  list  of  tasks 
for  each  AFSC  and  items  of  support  equipment.  The  input  data  can  be 
extracted  directly  from  LCOM  extended  form  11  data,  the  maintenance 
activity  network  data  file.  The  output  yields  the  "expected"  total 
maintenance  time  for  each  AFSC  and  use  time  for  each  item  of  support 
equipment  per  task. 

The  assessment  of  task  requirements  and  logistic  resources  pro¬ 
vided  by  EXPVAL  is  useful  for  the  following  procedures: 

a.  Maintenance  Action  Network  Procedure. 

b.  Integrated  Task  Analysis. 

c.  Procedure  Logistic  Resources  Assessment  Procedure. 

d.  Design  Option  Decision  Tree  Procedure. 
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CHAPTER  4.  INTEGRATION  WITH  ACQUISITION 


4.1  GENERAL 

Policy  for  Acquisition  Programs  is  established  in  Department  of 
Defense  Directive  (DoDD)  5000.1  and  Air  Force  Regulation  (AFR)  800-2 
for  Major  Systems  Acquisition.  Less-than-major-system  acquisition  pro¬ 
grams  follow  the  policy  for  major  systems.  Policy  for  Integrated 
Logistics  Support  (ILS)  for  major  systems  acquisition  is  established  in 
DoDD  5000.39  and  AFR  800-8.  These  require  that  ILS  planning  be  imple¬ 
mented  concurrently  with  acquisition  programs.  MIL-STD-1388,  Logistics 
Support  Analysis  (LSA),  is  applied  to  Acquisition  Programs  as  the 
single  analytical  process  for  the  ILS  Acquisition.  Systems  Acquisi¬ 
tion,  ILS  Planning,  and  LSA  are  all  initiated  at  Defense  System  Ac¬ 
quisition  Review  Council  (DSARC)  Milestone  0  (concept  exploration 
phase)  of  an  acquisition. 

The  ASSET  Technology  package  is  a  useful  set  of  procedures  and 
models  which  can  be  applied  early  in  an  Acquisition  Program,  i.e.,  at 
Milestone  0.  ASSET  is  applicable  to  and  compatible  with  the  Systems 
Acquisition  process  and  its  accompanying  ILS  and  LSA  processes,  and  is 
particularly  useful  during  the  DSARC  0,  concept  exploration  phase. 
This  section  presents  the  integration  of  the  ASSET  package  with  the  ac¬ 
quisition  process. 

4.2  CONCEPT  EXPLORATION  PHASE 

The  Concept  Exploration  Phase  (often  called  Conceptual  Phase  or 
Program  Initiation  Phase)  is  the  period  of  time  between  DSARC  0,  the 
milestone  at  which  the  "decision  to  acquire"  is  made  and  DSARC  I,  the 
milestone  at  which  the  "decision  to  proceed"  into  the  validation  and 
demonstration  phase  is  made.  The  conceptual  phase  is  devoted  to  what 
its  title  implies,  the  exploration  of  competing  concepts  which  satisfy 
the  need. 

This  ASSET  Guide  concentrates  on  the  application  and  use  of  ASSET 
in  the  conceptual  phase  of  an  Acquisition  Program,  fully  integrated 
into  the  Acquisition,  ILS,  and  LSA  processes. 

4.3  CONCEPTUAL  PHASE  DEFINITION 

In  order  to  readily  orient  the  user  of  this  guide  to  ASSET'S 
integration  into  an  acquisition  program  and  to  maintain  compatibility 
with  the  acquisition,  ILS,  and  LSA  processes,  the  conceptual  phase  is 
described  as  consisting  of  five  basic  events  which  typically  and  logic¬ 
ally  occur  between  the  DSARC  0  and  DSARC  I  decision  milestones,  i.e., 
during  the  conceptual  phase.  The  five  basic  events  are: 

a.  Requirements  Determination. 

b.  Conceptual  Systems  Design. 

c.  Conceptual  Support  Design. 
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d.  Evaluation  of  Concepts. 

e.  Concept  Selection. 

The  five  basic  events,  generic  in  nature,  are  also  descriptive  of 
follow-on  acquisition  phases,  with  only  definitive  details  being  dif¬ 
ferent,  as  an  acquisition  program  moves  through  its  phases  toward  de¬ 
ployment,  operations,  and  support. 

The  five  basic  events  are  time-based  measurements,  within  which  a 
number  of  tasks  and  subtasks  are  described,  the  number  dependent  upon 
the  complexity  of  the  Acquisition  Program. 

In  order  to  acquaint  the  user  of  this  guide  with  the  task  of  ASSET 
integration  into  an  acquisition  program,  certain  assumptions  are  made 
concerning  the  conceptual  phase.  The  five  basic  events  are  considered 
to  be  end-to-end,  and  considered  to  contain  a  given  number  of  first- 
level  tasks. 

The  user  will  understand  that  several  of  the  end-to-end  events 
(and  tasks)  could  actually  be  performed  in  parallel,  as  the  user 
"tailors"  the  typical  events  and  tasks  to  the  acquisition  program  of 
concern,  with  its  unique  characteristics.  In  addition,  the  user  will 
extend  each  first-level  task  down  to  sub-tasks  and  steps,  etc.,  to  the 
extent  necesary  to  suitably  define  the  depth  of  work  of  the  acquisition 
events. 

With  cognizance  of  the  foregoing  ground  rules,  this  guide  deline¬ 
ates  the  five  events  and  first-level  tasks  in  paragraph  4.4,  below. 
The  events  and  associated  tasks  are  given  convenient  numeric  designa¬ 
tions  which  can  be  extended  as  other  sub-tasks  (and  steps)  are  added. 
The  events  and  tasks  defined  are  applicable  to  both  Government  and  con¬ 
tractor  agencies. 


NOTE 

It  must  be  assumed  that  the  Government  has  accom¬ 
plished  certain  work  associated  with  the  DSARC  0 
decision  and  initiation  of  the  conceptual  phase  of 
the  acquisition,  such  as: 

a.  Mission  Element  Need  Statement  (MENS). 

b.  Statement  of  Operational  Need  (SON). 

c.  Budgeting  and  Funding  Process. 

d.  Issuance  of  Program  Management  Directive 
(PMD) . 

e.  Appointment  of  Acquisition  Systems  Program 
Officer  (SPO)  and  Deputy  Program  Manager  for 
Logistics  (DPML). 
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f.  Issuance  of  Program  Management  Plan  (PMP). 

g.  Issuance  of  a  Request  for  Proposal  (RFP)  with 
Statement  of  Work  (SOW),  Contractor  Data  Re¬ 
quirements  List  (CDRL)  and  accompanying 
documentation. 

4.4  CONCEPTUAL  PHASE  EVENTS  AND  TASKS 


Each  of  the  five  events  in  the  following  series  is  accompanied  by 
a  series  of  tasks  numbered  compatibly  to  the  event  number.  The  series 
represents  the  work  to  be  accomplished  in  a  "typical"  Acquisition  Con¬ 
ceptual  Phase,  expressed  generically  in  order  to  be  applicable  to  any 


type  of  Acquisition  Program.  The  series  of  events/tasks,  therefore, 
becomes  a  "roadmap"  that  can  be  followed  relative  to  progress  through 
the  conceptual  phase.  This  series  subsequently  becomes  the  reference 
for  integration  of  ASSET  techniques  into  the  appropriate  events/tasks 
of  a  program,  as  addressed  in  Paragraphs  4.5  and  4.6  below. 

EVENT  1.0 

REQUIREMENTS  DETERMINATION 

Task 

1.1 

Oata  Identification  and  Assembly 

Task 

1.2 

Data  Study  and  Assimilation 

Task 

1.3 

Data  Management  and  Distribution 

Task 

1.4 

Formulation  of  Mission  Requirements 

Task 

1.5 

Formulation  of  System  Design  Requirements 

Task 

1.6 

Formulation  of  Support  Design  Requirements 

Task 

1.7 

Identification  of  System/Support  Constraints 

Task 

1.8 

Documentation  of  Requirements 

Task 

1.9 

Documentation  of  Program  Performance,  Schedule  and 

Cost  Requirements 

EVENT  2.0 

CONCEPTUAL  SYSTEM  DESIGN 

Task 

2.1 

System  Capability  Definition 

Task 

2.2 

System  Interface  Definition 

Task 

2.3 

System  Design  Definition 

Task 

2.4 

System  R,  M,  S,  and  Supportabi 1 ity  Definition 

Task 

2.5 

System  Configuration  Definition 

Task 

2.6 

System  Operational  Scenario  Preparation 
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EVENT  2.0 
Task  2.7 
Task  2.8 
Task  2.9 


EVENT  3.0 
Task  3.1 
Task  3.2 
Task  3.3 
Task  3.4 
Task  3.5 
Task  3.6 
Task  3.7 
Task  3.8 
Task  3.9 
Task  3.10 


EVENT  4.0 
Task  4.1 


Task  4.2 
Task  4.3 


Task  4.4 


Task  4.5 


Task  4.6 


Task  4.7 
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CONCEPTUAL  SYSTEM  DESIGN  -  Continued 

Alternative  System(s)  Definition 

Documentation  of  System  Def inition(s) 

Documentation  of  System  Performance,  Schedule  and 
Cost 

CONCEPTUAL  SUPPORT  DESIGN 

Evaluation  of  Mission 

Evaluation  of  System  Operational  Scenario 

Analysis  of  System  Support  Tasks 

Formulation  of  Maintenance  Concept 

Formulation  of  Operational  Support  Scenario 

Definition  of  Support  Factors 

Definition  of  Support  Resources 

Definition  of  Support  Alternative(s) 

Documentation  of  Support  Def inition(s) 

Documentation  of  Support  Performance,  Schedule  and 
Cost 


EVALUATION  OF  CONCEPTS 

Quantify  Baseline  and  Alternative  Conceptual  System 
Designs 

Tradeoff  System  vs.  System  Alternatives 

Tradeoff  System  Element  vs.  System  Element 
Alternatives 

Quantify  Baseline  and  Alternative  Conceptual  Support 
Designs 

Tradeoff  Support  vs.  Support  Alternatives 

Tradeoff  Support  Element  vs.  Support  Element 
Alternatives 

Tradeoff  System  vs.  Support  Alternatives 
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EVENT  4.0 
Task  4.8 
Task  4.9 

Task  4.10 

Task  4.11 


EVALUATION  OF  CONCEPTS  -  Continued 
Evaluate  Optimal  System/Support  Combination 

Hoc umen t  M i ss i on/Oper at ion/System/Support 

Scenar io(s) 

Document  Risks  of  System/Support  Performance,  Sche¬ 
dule  and  Cost 

Document  Optimal  System/Support  Proposal 


EVENT  5.0 
Task  5.1 
Task  5.3 
Task  5.3 
Task  5.4 
Task  5.5 
Task  5.6 
Task  5.7 
Task  5.8 


CONCEPT  SELECTION 

Review  Mission/Operation/System/Support  Requirements 

Review  Acquisition  Program  Requirements 

Review  Source  Selection  Evaluation  Requirements 

Review  Each  System/Support  Proposal 

Tradeoff  Individual  Proposals 

Apply  Source  Selection  Evaluation  Criteria 

Select  Best  System/Support  Proposal (s) 

Document  Source  Selection  Recommendations 
NOTE 


It  must  be  assumed  that  the  Government  will  accom¬ 
plish  certain  work  associated  with  the  conclusion 
of  the  Conceptual  Phase  of  the  Acquisition  and  the 
DSARC  I  Decision,  such  as: 

a.  Decision  Coordination  Paper  (DCP). 

b.  DSARC  Process. 

c.  Review  of  MENS  and  SON. 

d.  Source  Selection  Process. 


e.  Budgeting  and  Funding  Process. 

f.  Preparation  for  DSARC  I  Validation  and  Demon¬ 
stration  Phase. 
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4.5  CONCEPTUAL  PHASE  ASSET  INTEGRATION 


Using  the  foregoing  generic  definition  of  the  events  and  tasks 
within  the  conceptual  phase  as  a  "roadmap",  the  user  may  insert,  or 
apply,  the  ASSET  procedures/models  as  required  to  secure  the  greatest 
benefits  to  the  user's  acquisition  program.  Also,  using  the  listed 
events  and  tasks  as  the  basis  of  a  typical  schedule,  this  guide  will 
integrate  the  ASSET  techniques  with  given  events  and  tasks  in  a  static 
manner,  representative  of  a  typical  acquisition. 

The  user  will  recognize  that  the  integration  of  ASSET  techniques 
is  flexible  and  adaptable  to  both  time-based  events  and  workdepth  tasks 
and  that  the  user  has  considerable  latitude  in  application.  An  under¬ 
standing  of  ASSET  capablities  and  benefits  and  of  acquisition  method¬ 
ology  is  a  requirement  for  successful  integration. 

Paragraph  4.6  addresses  identification  of  specific  events/tasks 
with  which  one  or  more  ASSET  techniques  may  be  integrated.  (The  actual 
application  procedure  for  ASSET  techniques  is  delineated  in  Section  V 
of  this  guide.)  Figure  1-12  is  a  matrix  displaying 
integration/application  relationships  of  events/tasks  *nd  ASSET 
procedures. 

4.6  ASSET  INTEGRATION 

This  paragraph  addresses  the  events  and  tasks,  delineated  in  Para¬ 
graph  4.4,  above,  and  selects  certain  representative  events  and  tasks 
with  which  the  several  ASSET  procedures  are  integrated.  The  matrix  in 
figure  1-12  is  a  simplified  illustration  of  the  integration.  The  user 
will  realize  that  tasks  not  addressed  are  significant  to  the  selected 
tasks,  as  they  either  provide  inputs  to  or  use  outputs  from  the  tasks 
selected  for  ASSET  integration.  (The  ASSET  models  are  not  addressed 
here,  as  they  are  implemented  by  the  ASSET  procedures.) 

4.6.1  Event  1,  Tasks  1.1  and  1.2 

The  Program  Definition  Analysis  Procedure  is  applied  to  the  tasks 
of  data  gathering,  study  and  reduction,  relative  to  all  requirements 
for  the  acquisition  and  its  program,  in  order  to  fully  define  the  ac¬ 
quisition  objectives. 

4.6.2  Event  1,  Tasks  1.3  through  1.9 

The  Consolidated  Data  Base  Procedure  is  applied  to  the  task  1.3  of 
establishing  a  data  bank  for  all  developed  requirements  and  for 
managing  it  for  use  of  all  future  data  generated  during  the  program. 

The  Program  Definition  Analysis  Procedure  is  applied  for 
continuing  study  and  reduction  of  all  requirements  data. 

4.6.3  Event  2,  Tasks  2.4  and  2.8;  Event  3,  Tasks  3.3  and  3.4 

The  Integrated  Task  Analysis  Procedure  is  applied  to  the  tasks  of 
analysis  of  system  reliability  and  maintainability  and  associated  data 
to  provide  a  basis  for  maintenance  support  studies. 


W482-520-065 


Figure  1-12.  ASSET  Procedure  Integration/Application  Matrix 


The  Maintenance  Action  Network  Procedure  is  applied  to  the  tasks 
of  formulating  a  maintenance  concept  in  support  of  the  system  support 
tasks  and  identifying  maintenance  requirements. 

The  Consolidated  Data  Base  Procedure  is  applied  to  enter  into  the 
data  base  the  results  of  the  associated  tasks. 

4.6.4  Event  3,  Tasks  3.6  through  3.9 

The  Logistics  Resource  Assessment  Procedure  is  applied  to  the 
definition  of  all  support  factors  leading  to  definition  of  specific  re¬ 
sources  and  alternatives  in  support  of  the  system  and  its  possible 
alternatives. 

The  Consolidated  Data  Base  Procedure  is  applied  to  assure  pre¬ 
servation  of  all  pertinent  data  derived  from  the  prior  tasks. 

4.6.5  Event  4,  Tasks  4.4  through  4.7 

The  Logistics  Resource  Assessment  Procedure  is  applied  to  the  re¬ 
fined  definition  of  all  alternative  resources  for  support  of  the  system 
and  alternatives. 

The  Comparability  Analysis  Procedure  is  applied  to  fully  defined 
support  resources  to  quantify  all  related  elements  in  terms  of  Life 
Cycle  Costs  through  comparison  with  an  equivalent,  existing  system. 

The  Life  Cycle  Cost  Assessment  Procedure  is  applied  to  fully 
defined  system  and  support  resources  and  alternatives  in  terms  of  the 
Life  Cycle  Cost. 

The  Consolidated  Data  Base  Procedure  is  applied  to  record  all 
significant  data  in  a  continuing  and  updating  process. 

4.6.6  Event  4,  Tasks  4.8  though  4.11 

The  Logistic  Resource  Assessment  Procedure  is  applied  to  iterated 
assessments  of  finalized  Logistics  Support  resources. 

The  Comparability  Analysis  Procedure  is  applied  to  finalized  up¬ 
dating  and  refined  Life  Cycle  Costing  factors. 

The  Life  Cycle  Cost  Assessment  Procedure  is  applied  to  system  and 
support  resources  evaluation  for  finalization  of  Life  Cycle  Costing 
analysis  criteria. 

The  Design  Option  Decision  Tree  Procedure  is  applied  to  aid  in  the 
visibility  on  alternatives  and  selection  of  the  optimal  logistic  re¬ 
sources  for  support  of  the  established  system. 

The  Consolidated  Data  Base  Procedure  is  applied  commensurately 
with  optimal  selection  of  resources  to  fully  identify  and  retain  all 
pertinent  data. 
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4.6.7  Event  2,  Tasks  2.8  and  2.9;  Event  3,  Tasks  3.9  and  3.10;  Event 
4,  Tasks  4.9  and  4.11 


The  Consolidated  Data  Base  Procedure  is  applied  for  a  complete 
audit,  evaluation,  screening  and  finalization  of  all  accumulated  data 
about  the  established  system  and  final  logistics  resources  selected. 


4.6.8  Event  5,  Tasks  5.5  and  5.7 


The  Logistics  Resources  Assessment  Procedure,  Life  Cycle  Cost 
Assessment  Procedure  and  Design  Option  Decision  Tree  Procedure  are 
collectively  applied  as  aids  in  the  decision  process  relative  to  selec¬ 
tion  of  the  optimal  system/resources  combination  among  several  compet¬ 
ing  system/resources  proposals. 


4.7  ASSET  PACKAGE  UTILIZATION 


The  foregoing  integration  of  the  ASSET  procedures  (and  combina¬ 
tions  of  procedures)  have  been  applied  to  the  previously  described 
events  and  tasks  inherent  in  a  "typical"  conceptual  phase  of  an  ac¬ 
quisition.  The  integration  is  not  rigidly  fixed,  but  used  relatively 
to  display  the  usefulness  of  the  ASSET  package  to  an  acquisition.  The 
user  has  a  considerable  number  of  integration  and  application  options 
for  meeting  the  actual  acquisition  program's  unique  schedules  and  task 
complexities.  The  user  can  extend  or  compress  schedules,  increase  or 
decrease  task  depth  and  place  tasks  into  either  sequential  or  parallel 
orders  for  accomplishment.  The  purpose  of  the  integration  guide  is  to 
aid  and  assist  the  user  in  the  realization  of  the  benefits  of  integrat¬ 
ing  the  ASSET  package  into  the  acquisition  independently,  in  conjunc¬ 
tion  with  ILS  planning  in  accordance  with  DoDD  5000.39  and  AFR  800-8, 
and/or  in  conjunction  with  MIL-STD-1388  LSA. 
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CHAPTER  5.  APPLICATION  OF  THE  ASSET  METHODOLOGY 


The  ASSET  methodology  is  applied  to  a  weapon  system  during  its 
acquisition  process  in  order  to  impact  the  design  and  acquisition  deci¬ 
sion  with  supportabi 1 i ty  cons iderations.  The  ASSET  analysis  is  applied 
or  accomplished  through  a  series  of  analysis  procedures,  each  of  which 
details  the  possible  use  of  ore  or  more  of  the  individual  ASSET  models. 

This  chapter  presents  the  analysis  procedures  in  an  order  in  which 
they  would  be  applied  in  a  weapon  system  acquisition  program.  Each 
procedure  is  presented  in  sufficient  detailed  tasks  and  steps  as  to 
provide  the  user  with  a  plan  to  apply  the  procedure  and  thus  to  apply 
the  ASSET  methodology. 

Not  all  procedures  and  tasks  included  in  the  procedures  are 
mandatory  in  an  application  program,  although  the  relative  ordering  of 
the  procedures  and  tasks  must  be  maintained.  The  application  may  be 
tailored  to  an  individual  program  through  decisions  to  include  or  omit 
specific  tasks.  This  tailoring  is  initially  accomplished  as  part  of 
the  first  procedure,  the  Program  Definition  Analysis  Procedure.  Deci¬ 
sions  as  to  which  models  and  techniques  to  use  in  the  accomplishment  of 
each  procedure  may  also  be  made  at  the  same  time  or  may  be  deferred  to 
the  time  of  the  particular  procedure  application. 

5.1  PROGRAM  DEFINITION  ANALYSIS  PROCEDURE 

This  is  the  critical  first  step  in  the  application  of  ASSET 
through  which  the  logistical  analysis  program,  effort  and  goals  are 
established.  Based  on  the  application  program  defined,  the  ASSET  pro¬ 
cedures  are  reviewed  and  a  decision  made  as  to  the  application  and 
timing  of  each. 

There  is  a  series  of  questions  which  must  be  answered  during  the 
program  definition  analysis.  The  answers  serve  to  define  the  total 
scope  and  detail  of  the  ASSET  application.  This  is  not  to  say  the 
decisions  made  now  are  irreversible  or  cannot  be  altered,  for  the  scope 
and/or  level  of  detail  of  each  procedure  can  be  altered  during  the  per¬ 
formance  of  the  particular  procedure.  An  initial  decision  on  the  ap¬ 
plicable  computer  models  to  be  used  in  the  weapon  system  analysis  can 
also  be  made  during  this  analysis.  This  too  may  be  changed  in  response 
to  specific  requirements  or  system  data  availability. 

A  sample  of  the  items  which  must  be  addressed  during  the  PDA  is 
presented  below: 

a.  Weapon  System  Identification. 

b.  Equipment  Hierarchy. 

c.  Comparable  System  or  Subsystem  Identification. 

d.  Logistic  Resources  Requirements  Needed. 
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e.  Life  Cycle  Cost  Assessment  Required. 

f.  Depth  of  Task  Analysis  Required. 

5.2  CONSOLIDATED  DATA  BASE  (CDB)  PROCEDURE 

Consolidated  data  base  (CDB)  is  the  term  used  to  describe  the 
central  depository  for  all  data  required  for  the  application  of  ASSET. 
The  CDB  includes  the  general  categories  of  program  requirements,  logis¬ 
tics  support  assumptions  and  constraints,  and  manual  logistics  plans  as 
well  as  data  files  in  the  computer  sense  which  are  required  for  the 
application  and  execution  of  the  models  associated  with  ASSET.  The  CDB 
is  structured  in  such  a  manner  as  to  be  compatible  with  the  logistics 
support  analysis  record  (LSAR)  for  later  transition  to  this  medium  when 
or  if  required. 

The  generic  events  or  tasks  to  be  accomplished  in  the  initial  es¬ 
tablishment  of  the  CDS  are  outlined  below: 

a.  Data  Management  and  Distribution  Definition. 

b.  Data  Categories  Identification  and  Assembly. 

c.  Data  Study  and  Assimilation. 

d.  Data  Documentation. 

The  CDB  is  established  initially  in  an  ASSET  application  in  line 
with  the  program  definition  determined  through  the  program  definition 
analysis.  The  control  and  administration  aspects  of  the  CDB  are  also 
established  to  centralize  authority  to  control  the  data  and  limit  the 
ability  to  alter  or  update  data  thus  ensuring  validated  data.  Control 
is  established  to  permit  data  relating  to  the  multiple  alternatives  for 
system  design  and  support  concepts  and  provide  a  means  for  separating 
the  data  for  each  alternative  to  avoid  confusion. 

The  detailed  structure  of  the  CDB  was  initially  described  in  a 
functional  specification  contained  in  AFHRL-TR-78-6  (III).  The  major 
categories,  as  defined  by  this  specification  were  the  six  listed  below: 

a.  Maintenance  Data. 

b.  Equipment  Data. 

c.  Operations  Data. 

d.  Cost  Data. 

e.  Alternate  Data. 

f.  Decision  Data. 
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These  categories  have  now  been  modified  and  new  categories  included  to 
expand  the  CDB  and  facilitate  interface  with  or  transition  to  a  logis¬ 
tics  support  analysis  record  ( LSAR )  data  bank. 


The  categories  of  data  to  be  included  for  documentation  in  the  CDB 
are  listed  below  and  shown  in  figure  1-13. 

a.  Weapon  System  Identification  and  Requirements. 

b.  Program  Directives  and  Scenario. 

c.  Maintenance  Concept. 

d.  Reliability  Data. 

e.  Maintainability  Data. 

f.  Tasks,  Personnel  and  Training  Data. 

g.  Support  Equipment. 

h.  Facilities. 

i.  Software. 

j.  Technical  Manuals. 

k.  Costing  Data. 

Figure  1-14  presents  a  matrix  showing  the  correlation  between  the 
six  categories  in  the  initial  functional  specification  and  the  eleven 
present  categories.  The  new  categories  added  are: 

a.  Program  Directives  and  Scenarios. 

b.  Maintenance  Concept. 

c.  Support  Equipment. 

d.  Facilities. 

e.  Software. 

f.  Technical  Manuals. 

The  following  paragraphs  present  a  description  of  each  of  the  CDB 
categories. 

5.2.1  Weapon  System  Identification  and  Requirements 

The  primary  results  of  the  Program  Definition  Analysis  are 
recorded  in  this  category.  Included  are  the  weapon  system  requirements 
and  the  associated  support  system  requirements.  The  weapon  system 
equipment  hierarchy  is  also  recorded  here  as  well  as  the  identification 
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Figure  1-13.  Consolidated  Data  Base 
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of  alternate  systems  or  configurations  of  interest  for  analysis.  In¬ 
cluded  with  the  alternative  identification  will  be  any  DODT(s)  con¬ 
structed  for  the  weapon  system. 

5.2.2  Program  Directives  and  Scenario 

Included  in  this  category  are  the  Mission  Element  Need  Statement 
(MENS)  and  Statement  of  Operational  Need  (SON)  for  the  weapon  system. 
All  program  directives  generated  are  also  recorded  in  this  category. 
The  definition  and  description  of  the  operation  scenario,  contained  in 
the  MENS  and  SON,  must  be  specifically  documented  to  allow  reference 
for  impact  on  the  support  system. 

5.2.3  Maintenance  Concept 

The  decisions  evolving  into  the  system  maintenance  concept  are 
recorded  in  this  category  of  the  CDB.  Items  include  the  diagrams  of 
maintenance  flow  in  support  of  the  weapon  system  and  the  maintenance 
action  networks  developed  to  depict  the  maintenance  concept  and  weapon 
system  availability  requirements. 

The  life  cycle  cost  estimate  for  the  maintenance  concept  and  pos¬ 
sible  alternatives  is  also  recorded  with  the  appropriate  concept. 

The  weapon  system  integrated  logistics  support  plan  (ILSP),  inte¬ 
grated  support  plan  (ISP),  and  maintenance  plan  (MP)  are  included  when 
prepared. 

5.2.4  Reliability  Data 

All  data  relating  to  the  reliability  of  the  weapon  system  and 
associated  support  system,  either  in  total  or  for  subcomponents 
thereof,  is  recorded  in  the  CDB.  Specific  elements  include: 

a.  Reliability  Requirements. 

b.  Failure  Mode  Identification. 

c.  Failure  Effects  Analysis. 

d.  Failure  Rates. 

e.  Mean  Time  Between  Failures  (MTBF). 

f.  Mean  Flying  Hours  Between  Maintenance  Actions  (MFHBMA). 

5.2.5  Maintainability  Data 

All  data  relating  to  the  maintainability  of  the  weapon  system  and 
associated  support  system,  either  in  total  or  for  subcomponents 
thereof,  is  recorded  in  this  category  of  the  CDB.  Specific  elements 
include: 


a.  Maintainability  Requirements. 
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(1)  Test  Requirements. 

(?)  Built-in-Test  (BIT)  Requirements. 

b.  Mean  Time  to  Repair  (MTTR). 

c.  Avai labi I i ty  Requirements. 

5.2.6  Tasks,  Personnel  and  Training  Data 

This  category  of  the  CDB  is  used  to  record  the  information 
gathered  and  generated  through  the  integrated  task  analysis  procedure. 
Data  includes  that  which  identifies  the  tasks  relating  to  the  weapon 
system,  personnel  requirements  and  availability,  and  skills  and  train¬ 
ing  requirements  for  these  personnel. 

Within  this  category,  the  weapon  system  operation  data  and  mainte¬ 
nance  data  are  separated,  thus  creating  two  major  subcategories.  Spe¬ 
cific  elements  included  in  each  subcategory  are: 

a.  Task  Identification. 

b.  Manpower  Requirements. 

c.  Personnel  Requirements. 

(1)  Skill  Level. 

(2)  Air  Force  Specialty  Code. 

d.  Personnel  Availability. 

e.  Tool  Requirements. 

f.  Training  Requirements. 

5.2.7  Support  Equipment 

Requirements  for  items  of  support  equipment  to  support  the  weapon 
systems  are  recorded  in  this  category  of  the  CDB.  Information  defining 
and  describing  the  support  equipment  such  as  tasks  which  require  it, 
measurement  ranges  and  tolerances,  and  power  requirements,  are  docu¬ 
mented  to  the  depth  and  level  of  detail  permissible  with  the  avail¬ 
ability  of  this  data. 

5.2.8  Facilities 

Facilities  required  for  the  operation  and  support  of  the  weapon 
system  are  identified  through  the  integrated  task  analysis  procedure 
and  documented  in  this  category  of  the  CDB.  As  information  is  gathered 
and  requirements  firmed,  the  recorded  facility  needs  are  annotated  as 
to  whether  existing  facilities  are  sufficient  for  use  or  new  facilities 
are  required. 


5.2.9  Software 


This  category  of  the  CDB  is  used  to  document  software  requirements 
of  the  weapon  system  when  required. 

5.2.10  Technical  Manuals 

This  category  is  used  to  document  requirements  for  technical  man¬ 
uals  in  support  of  the  weapon  system.  Initially,  a  list  of  the  requi¬ 
site  manuals  is  recorded.  As  more  information  is  available,  estimates 
of  content  and  number  of  pages  are  recorded.  Copies  of  technical  man¬ 
ual  drafts  and  final  products  are  included  when  prepared. 

5.2.11  Costing  Data 

Costing  data  required  to  conduct  a  life  cycle  cost  assessment  and 
analysis  is  recorded  in  this  category.  Also  included  is  the  identifi¬ 
cation  of  the  LCC  model  used  and  results  of  the  analysis. 

5.3  INTEGRATED  TASK  ANALYSIS  PROCEDURE 

The  integrated  task  analysis  in  ASSET  is  ..he  systematic  study  of 
the  requirements  for  tasks  which  must  be  performed  to  operate  and  main¬ 
tain  a  weapon  system.  The  goals  of  this  analysis  are: 

a.  Identification  of  task  relating  to  the  weapon  system  and 
equipment. 

b.  Identification  of  logistic  resources  required  by  the  tasks  and 
allocation  of  these  for  task  performance. 

c.  Task  performance  descriptions  to  assist  in  training  and  tech¬ 
nical  publication  planning. 

There  are  essentially  two  levels  of  task  analysis:  (1)  the  ini¬ 
tial  task  identification,  and  (2)  the  subsequent  detailed  analysis  of 
the  identified  tasks.  The  second  level,  in  turn,  encompasses  many 
levels  of  analysis  relating  to  the  scope  and  level  of  detail  required 
by  the  particular  acquisition  phase  and  the  limits  or  constraints  of 
the  available  data  to  accomplish  the  task  analysis.  With  respect  to 
this,  the  integrated  task  analysis  is  an  iterative  task  with  further 
depth  and  detail  provided  with  the  timing  of  data  availability. 

The  principal  activities  or  tasks  constituting  the  ITA  are  as  out¬ 
lined  below: 

a.  Review  System  Operation  and  Support  Concepts. 

b.  Define  Operation  and  Maintenance  Tasks. 

c.  Develop  Preliminary  Task  Identification  Matrix. 

d.  Define  and  Assign  Personnel  and  Skill  Requirements. 


e.  Define  and  Allocate  Support  Equipment. 

f.  Determine  Tasks  Recording  Formats. 

g.  Define  or  Review  Level  of  Detail  Guide. 

h.  Perform  Task  Performance  Analysis. 

i.  Record  Tool  and  Test  Equipment  Requirements. 

5.4  MAINTENANCE  ACTION  NETWORK  PROCEDURE 

The  maintenance  action  network  (MAN)  procedure  acts  as  an  inter¬ 
face  linkage  between  the  integrated  task  analysis  procedure  and  the 
logistic  resources  assessment  procedure.  Through  the  MAN  procedure,  a 
maintenance  action  network  is  generated  which  depicts  the  maintenance 
concept  for  the  weapon  system.  From  this,  a  general  maintenance  flow 
diagram  can  be  constructed.  As  data  is  made  available  through  the 
ASSET  procedures,  the  MAN  is  annotated  with  probabilities  of  events  or 
tasks,  personnel  and  skill  requirements,  support  equipment  requirements 
and  mean  task  performance  time. 

The  form  and  complexity  of  the  maintenance  action  network  can  vary 
depending  on  the  analysis  technique  chosen.  Within  ASSET,  the  analysis 
techniques  available  are  manual,  the  use  of  the  RM  model  and  RMCM  or 
the  use  of  LCOM  and/or  EXPVAL.  Thus,  this  decision  must  be  made  before 
the  MAN  is  expanded. 

The  tasks  performed  during  the  MAN  procedure  are  outlined  below: 

a.  Construct  Basic  MAN. 

b.  Decide  on  Analysis  Techniques. 

(1)  Manual. 

(2)  RM/RMCM. 

(3)  LCOM/EXPVAL . 

c.  Expand  MAN  as  Required. 

d.  Determine  Task  Probabilities. 

e.  Record  Personnel  and  Skill  Requirements. 

f.  Record  Mean  Task  Time. 

g.  Allocate  Support  Equipment. 

The  data  used  to  annotate  the  MAN  is  generally  obtained  during  the 
integrated  task  analysis  procedure.  The  recorded  data  is  then  utilized 
in  the  logistic  resources  assessment  procedure  and  life  cycle  cost 


assessment  procedure  to  identify  and  analyze  the  weapon  system's  sup¬ 
port  requirements. 

5.5  LOGISTIC  RESOURCES  ASSESSMENT  PROCEDURE 

Through  the  accomplishment  of  this  procedure,  the  first  analytical 
indication  of  the  logistic  resources  required  by  the  system  is 
determined.  The  performance  of  this  assessment  begins  with  the  initial 
task  analysis.  This  is  expanded  into  a  more  detailed  analysis  with  a 
review  of  the  support  requirements  and  resources  needed  to  fulfill  or 
complete  the  identified  tasks.  These  resources  include,  but  are  not 
limited  to,  manpower,  personnel  and  skills,  support  equipment,  spares, 
facilities,  technical  manuals  and  documentation,  and  training 
requirements. 

This  task  generally  requires  the  use  of  the  associated  analytical 
computer  models  to  specify  and  track  resource  requirements.  The  deci¬ 
sion  as  to  which  models  to  use  must  be  made  early  for  this  decision 
will  impact  further  procedural  tasks. 

A  general  listing  of  the  tasks  included  in  the  logistic  resources 
assessment  procedure  is  outlined  below: 

a.  Review  Integrated  Task  Analysis. 

b.  Review  Maintenance  Action  Network. 

c.  Decision  on  Technique. 

(1)  Manual. 

(2)  Average  Value. 

(3)  Dynamic  Simulation. 

d.  Gather  Data. 

e.  Allocate  Support  Equipment. 

f.  Execute  Assessment. 

g.  Analysis. 

h.  TAM  Utilization. 

i.  PAGES  Utilization. 

5.6  COMPARABILITY  ANALYSIS  PROCEDURE 

Within  the  ASSET  application,  the  comparability  analysis  is  con¬ 
ducted  to  f  :ract  information  on  the  weapon  system  support.  A  compar¬ 
ability  ana.ysis  refers  to  the  overall  process  used  to  develop  data  on 
newly  proposed  or  designed  weapon  systems  by  (1)  selecting  operational 
equipment  similar  to  that  of  the  proposed  weapon  system  and 


(2)  adjusting  the  resource  data  associated  with  operational  equipment 
to  reflect  the  unique  character istics  of  the  proposed  equipment.  The 
comparabi 1 i ty  analysis  includes  a  requirement  for  finding  operational 
equipment  that  is  similar  to  the  proposed  equipment.  It  also  includes 
the  development  of  maintenance  demand  rates  for  the  proposed  equipment 
which,  in  turn,  can  be  used  to  determine  resource  requirements  (such  as 
manpower,  support  equipment,  and  spares  for  the  weapon  system). 

The  comparability  analysis  is  initiated  using  the  outline  of  the 
proposed  or  newly  developed  weapon  system  and  the  comparable  system 
identified  during  the  program  definition  analysis.  Data  elements 
required  to  complete  or  refine  either  the  logistic  resources  assessment 
or  the  life  cycle  cost  assessment  are  identified  and  similar  elements 
relating  to  the  comparable  system  are  modified  for  usage. 

5.7  LIFE  CYCLE  COST  ASSESSMENT  PROCEDURE 

The  assessment  of  the  life  cycle  cost  (LCC)  for  a  weapon  system  is 
one  of  the  most  visible  products  of  the  ASSET  application.  As  such, 
the  analyst  must  be  cautious  to  ensure  cost  data  elements  are  accurate 
reflections  and  forecasts  of  those  which  will  be  presented  by  the  sys¬ 
tem  under  analysis.  Placing  the  life  cycle  cost  assessment  after  the 
logistic  resources  assessment  enables  the  initial  task  analysis  and  the 
logistic  resources  assessment  to  be  conducted  prior  to  a  cost  analysis. 

The  LCC  assessment  procedure  in  ASSET  centers  on  the  use  of  the 
RMCM.  The  analyst  must  be  familiar  with  the  assumptions  and  capabil¬ 
ities  of  this  model  before  initiating  the  LCC  assessment.  The  required 
data  is  then  collected  and  the  assessment  analysis  is  begun. 

The  identification  and  collection  of  data  for  the  LCC  assessment 
is  a  function  of  the  application  program  requirements.  The  identifi¬ 
cation  of  applicable  and  appropriate  data  should  be  accomplished  before 
much  effort  is  spent  in  what  may  be  non-essential  activities.  THE  RMCM 
addresses  the  recurring  and  non-recurring  costs  (including  system  dis¬ 
posal  costs)  of  a  weapon  system.  Some  of  these  costs  may  not  be  of 
interest  in  a  particular  application  program.  Examples  of  these  are 
the  costs  of  system  disposal,  research  and  development,  fuel,  and  soft¬ 
ware  development. 

5.8  DESIGN  OPTION  DECISION  TREE  PROCEDURE 

The  DODT  procedure  within  ASSET  provides  a  means  to  inject  sup- 
portability  factors  into  the  existing  DODT  methodology.  A  support- 
ability  evaluation  is  given  for  selected  alternatives  in  the  weapon 
system  or  subsystem  DODT. 

The  DODT  procedure  is  listed  as  the  final  ASSET  procedure,  not  be¬ 
cause  it  is  necessarily  the  last  one  to  be  performed  but  because  the 
procedure  into, faces  with  an  existing  methodology  and  relies  on  the 
other  ASSET  procedure  to  generate  data  for  application.  Examples  of 
the  supportability  considerations  which  may  be  acknowledged  on  the  DODT 


a.  Personnel  and  Skill  Requirements. 

b.  Support  Equipment  Requirements. 

c.  Facility  Requirements. 

d.  Availability  Estimates. 

e.  Total  Life  Cycle  Cost. 

f.  Components  of  LCC. 

g.  FOMs  Detailed  by  the  RM  Model. 

The  generation  of  these  considerations  is  performed  by  the  appli 
cation  of  the  appropriate  procedure. 


END 
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